Читать онлайн «Очерки истории отечественной программной инженерии в 1940-е – 80-е годы». Страница 49

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

В 1950-е – 60-е годы к созданию программ для ЭВМ исторически подходили, как к «искусству и художественному творчеству» отдельных специалистов или небольших групп. При этом считалось, что невозможно применять, какие-либо экономические характеристики для определения стоимости и результатов такого творчества, и они оценивались только с позиции качества выполняемых функций и «эстетики» их реализации. Такие программы создавались преимущественно для получения конкретных результатов исследований или для анализа относительно простых процессов обработки информации. Они не предназначены для массового тиражирования и распространения как программный продукт на рынке, их оценивали качественно и интуитивно, преимущественно как «художественные произведения». При этом, как правило, не было конкретного заказчика-потребителя, определяющего требования к программам и их финансирование, программы не ограничивали допустимой стоимостью, трудоемкостью и сроками их создания, требованиями обеспечения заданного качества и документирования. Их разработчики не применяли регламентирующих, нормативных документов, вследствие чего жизненный цикл таких изделий имел не предсказуемый характер по качеству и стоимости основных результатов «творчества».

Для небольших относительно простых программных комплексов, во многих случаях, достаточно достоверными могли быть интуитивные оценки требуемых экономических ресурсов, выполняемые опытными руководителями, реализовавшими несколько аналогичных проектов. Такие оценки отличались большими ошибками при планировании экономических характеристик — сроков, трудоемкости и стоимости создания сложных программных продуктов. В большинстве случаев, это приводило к значительному запаздыванию завершения разработок и превышению предполагавшихся затрат ресурсов. Вследствие пренебрежения тщательным экономическим обоснованием, до 15 % проектов сложных программных комплексов не доходило до завершения, а почти половина проектов не укладывалось в выделенные ресурсы, бюджет и сроки, не обеспечивало требуемые характеристики качества. Отставание сроков внедрения некоторых больших промышленных и оборонных систем управления и обработки информации полностью зависело от неготовности для них программных продуктов.

Массовое создание сложных и дорогих программных продуктов промышленными методами и большими коллективами специалистов (в основном для оборонных систем) вызвало необходимость их достоверного экономического прогнозирования и анализа, четкой организации производства, планирования работ по затратам, этапам и срокам реализации. Для решения этих задач в 70-е годы начала формироваться новая область знания и инженерная дисциплина – экономика, создания сложных программных продуктов [15, 11]. Необходимо было освоить анализ и оценивание конкретных факторов, влияющих на экономические характеристики проектов программных продуктов вследствие реально существующих и потенциально возможных воздействий и ограничений ресурсов проектов комплексов программ. Это привело к появлению новой области экономической науки и практики – экономики проектирования, производства и жизненного цикла сложных программных продуктов, как части экономики в промышленности и вычислительной технике в составе общей экономики некоторых предприятий. Ее основной задачей являлись анализ, прогнозирование, эффективное управление, распределение ресурсов и экономное их использование.

Развитие этой области экономики было связано с большими профессиональными и психологическими трудностями, типичными для новых разделов современной науки и техники, появляющимися на стыке различных областей методов и знаний. В данном случае особенности состояли в том, что менеджеры и разработчики сложных комплексов программ, как правило, не знали даже основ экономики промышленного производства сложной технической продукции, а экономисты не представляли сущность и свойства объектов разработки – программных продуктов, а также особенностей технологических процессов их производства и применения. Широкий спектр технических характеристик таких объектов, количественных и качественных факторов, которые с различных сторон характеризуют содержание компонентов и комплексов программ, и невысокая достоверность оценки их значений, определяли значительные трудности при попытке описать и измерить свойства и качество создаваемых или используемых сложных программных продуктов для их экономической оценки и прогнозирования характеристик.

Приступая к созданию сложных технических проектов, заказчики и исполнители, прежде всего, должны были понять целесообразна ли их разработка и оценить возможную эффективность применения готового продукта, оправдаются ли затраты на его производство и использование. Поэтому такие технические проекты в промышленности традиционно начинались с анализа и экономического обоснования предстоящего производства и применения предполагаемого продукта или системы. Заказчику и возможным потребителям результатов проекта необходимо оценивать реальную потребность в его создании и конкурентоспособность, а потенциальному разработчику предполагаемого продукта, проводить оценку реализуемости проекта при условиях и ресурсах, предлагаемых заказчиком. Однако часто разработчики не в состоянии привести заказчику или руководителю проекта достаточно обоснованные доказательства не реальности выполнения выдвигаемых требований к продукту при предложенных ограниченных значениях бюджета и сроков. Руководители конкретных проектов обычно не в состоянии достаточно обоснованно определять, сколько времени и затрат труда потребуется на каждый этап проекта системы, и не могут оценить, насколько успешно выполняется план производства. Это, как правило, означает, что проект системы с самого начала выходит из-под экономического контроля и возможна катастрофа с реализацией и завершением проекта всей системы в требуемый срок с заданным бюджетом и качеством.

Создание в 1970-е – 80-е годы сложных программных комплексов как производственной продукции существенно повысило актуальность экономического обоснования, необходимость прогнозирования и измерения процессов производства и их характеристик качества. Основной целью производства многих программных продуктов является повышение эффективности промышленных систем обработки информации и/или управления объектами и административными системами, в которых применяются сложные комплексы программ. Такими системами могли быть средства автоматизированного управления в авиации, космическими системами, энергосистемами, системами административного управления, автоматизации проектирования.

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

• создание и весь жизненный цикл комплексов программ ориентируется на массовое тиражирование и распространение их на рынке, среди заранее не известных пользователей, в различных сферах и внешней среде применения; при этом отсутствует конкретный внешний потребитель – заказчик, который определяет и диктует основные требования к программному продукту, выделяет ресурсы и финансирует проект;