Оценка необходимых ресурсов для реализации
Многие проекты обеспечения безопасности систем терпели и терпят неудачу из-за отсутствия у разработчиков и заказчиков при подготовке контракта четкого представления о реальных финансовых, трудовых, временных и иных ресурсах, необходимых и доступных для их реализации. Поэтому одной из основных задач при проектировании функциональной безопасности ПС является экономический анализ и определение необходимых ресурсов для создания и всего ЖЦ ПС в соответствии с требованиями контракта и технического задания [2], [5], [10].
При планировании проектов ПС часто инициатором разработки является разработчик-поставщик, который самостоятельно принимает все решения о проектировании за счет собственных ресурсов и предполагает возместить затраты при реализации ПС на рынке. В других случаях имеется определенный заказчик-потребитель, который способен задать основные цели, характеристики качества и безопасности и обеспечить ресурсы для реализации проекта. Таким образом, при экономическом обосновании проектов ПС и их функциональной безопасности возможны два сценария:
· создание и весь жизненный цикл комплекса программ и/или базы данных ориентируется разработчиком на массовое тиражирование и распространение на рынке для заранее неизвестных покупателей-пользователей в различных сферах применения, при этом отсутствует приоритетный внешний потребитель-заказчик, который определяет и диктует основные требования к ПС и его безопасности, а также финансирует проект;
· разработка проекта ПС и/или БД и их безопасности предполагается поставщиком-разработчиком для конкретного потребителя-заказчика, задающего все требования, который его финансирует, с определенным, необходимым ему тиражом и известной ограниченной областью применения результатов разработки.
Первый сценарий базируется на маркетинговых исследованиях рынка программных продуктов и на стремлении поставщика занять на рынке достаточно выгодное место, обеспечивающее ему необходимую прибыль. Важнейшим фактором конкурентоспособности ПС является соотношение между ценностью (эффективностью) имеющегося или предполагаемого продукта с позиции его использования потребителем и стоимостью его при создании или приобретении в условиях реального рынка. Для этого нужно определить наличие на рынке гаммы близких по назначению ПС, оценить их экономическую эффективность, стоимость, применяемость и безопасность, а также возможную конкурентоспособность предполагаемого программного продукта для потенциальных пользователей и их возможное число. Кроме того, следует оценить рентабельность затрат на обеспечение всего ЖЦ нового ПС и выявить функциональные и конструктивные характеристики качества и безопасности, которые способны привлечь достаточно покупателей и оправдать затраты на предстоящую разработку.
Второй сценарий предполагает наличие определенного заказчика-потребителя проекта ПС, который определяет основные технические и экономические требования и функциональные характеристики. Он выбирает конкурентоспособного поставщика-разработчика, которого оценивает на возможность реализовать проект с необходимым качеством и функциональной безопасностью с учетом ограничения сроков, бюджета и других ресурсов. Этому помогает опыт и экономические характеристики ранее выполненных поставщиками проектов, но некоторые проекты могут не иметь явных прецедентов, и тогда приходится использовать имеющуюся статистику в этой области. При этом предполагается, что результаты разработки могут не поступать на открытый рынок, вследствие чего маркетинговые исследования для таких проектов не являются доминирующими и обычно предварительно могут не проводиться.
При прогнозировании необходимых ресурсов для проекта, ЖЦ ПС и обеспечение его безопасности можно разделить на две части, существенно различающиеся экономическими особенностями процессов, характеристиками и влияющими на них факторами. В первой части ЖЦ производятся системный анализ, проектирование, разработка, тестирование и испытания базовой версии ПС. Номенклатура работ, их трудоемкость, длительность и другие экономические характеристики на этих этапах ЖЦ существенно зависят от требуемых характеристик системы и ее безопасности, технологии и инструментальной среды разработки.
Вторая часть ЖЦ ПС, отражающая эксплуатацию, сопровождение, модификацию и перенос ПС на иные платформы, в меньшей степени связана с функциональными характеристиками системы и среды разработки. Номенклатура работ на этих этапах более или менее определенная и стандартизированная (см. ISO 12207, ISO 14764, ISO 15846), но их трудоемкость и длительность могут сильно варьироваться в зависимости от массовости и других внешних факторов распространения и применения версий ПС. Определяющими становятся потребительские характеристики ПС, а их экономические особенности с позиции разработчиков и вложенные затраты на очередную версию отходят на второй план (см. первый сценарий). Поэтому планы на этих этапах имеют характер общих взаимосвязей содержания работ, которые требуют распределения во времени индивидуально для каждого проекта.
Важнейшим ресурсом при создании любых ПС являются люди — специалисты с их уровнем профессиональной квалификации, а также с многообразием знаний, опыта, стимулов и потребностей. Быстрый рост сложности и повышение ответственности за качество и функциональную безопасность комплексов программ привели к появлению новых требований к специалистам, обеспечивающим все этапы жизненного цикла ПС. Эти специалисты должны владеть новой интеллектуальной профессией, обеспечивающей высокое качество и безопасность ЖЦ ПС, а также контроль, испытания и удостоверение реального достигнутого качества на каждом этапе разработки и совершенствования программ.
Безопасность вычислительной системы с ПС обеспечивается двумя видами работ: созданием функциональных программ высокого качества с минимальным количеством дефектов и ошибок, отражающихся на безопасности, и разработкой специального комплекса программ, повышающих безопасность функционирования основных программ. Руководство безопасностью сложного проекта ПС должны осуществлять лидеры — менеджеры:
· менеджер безопасности проекта — это специалист, обеспечивающий коммуникацию между заказчиком и проектной командой специалистов, его задача — определить и обеспечить полное удовлетворение требований заказчика по безопасности системы и ПС;
· менеджер-архитектор комплекса программ повышения безопасности — управляет коммуникациями и взаимоотношениями в проектной команде, является координатором создания компонентов, разрабатывает базовые, функциональные спецификации и управляет ими, ведет график проекта и отчитывается за его состояние, инициирует принятие критичных для хода проекта решений.
Функции специалистов и технология работы при обеспечении ЖЦ комплекса программ повышения безопасности ПС аналогичны тем, которые применяются при создании основных компонентов, определяющих функциональную пригодность ПС и системы. В реализации любого крупного проекта ПС можно выделить две категории специалистов: разрабатывающих компоненты и ПС в целом и обеспечивающие технологию, безопасность и качество программного продукта. При выборе заказчиком надежного поставщика-разработчика проекта необходима оценка тематической и технологической квалификации возможного коллектива специалистов, а также его способности реализовать проект с заданными требованиями, качеством и функциональной безопасностью.
Специалисты первой категории непосредственно создают компоненты и ПС в целом с заданными показателями качества и безопасности. В процессе разработки их функции заключаются в тщательном соблюдении принятой в фирме технологии и в формировании всех предписанных руководствами исходных и отчетных документов. Разделение труда специалистов этой категории в крупных проектных коллективах приводит к необходимости их дифференциации по квалификации и областям деятельности:
· спецификаторы — подготавливают описания функций соответствующих компонентов с уровнем детализации, достаточным для корректной разработки текстов программ программистами;
· разработчики программных компонентов (программисты) создают компоненты, удовлетворяющие спецификациям, реализуют требуемые функции продукта;
· системные интеграторы создают на выходе требуемые крупные компоненты или комплекс программ;
· тестировщики — обеспечивают проверку функциональных спецификаций, выполняют тестирование для каждой из фаз и компонента проекта;
· управляющие сопровождением и конфигурацией — обеспечивают взаимодействие компонентов и реализацию версий ПС;
· документаторы — осуществляют подготовку и издание сводных технологических и эксплуатационных документов в соответствие с требованиями стандартов.
Специалисты второй категории — технологи, обслуживающие и сопровождающие технологический инструментарий, который применяется специалистами первой категории, обеспечивают применение системы качества проекта или предприятия, контролируют и инспектируют ее использование. Специалисты, управляющие обеспечением качества и безопасности ПС, должны овладеть стандартами и методиками фирмы, поддерживающими регистрацию, контроль, документирование и воздействия на показатели качества на всех этапах ЖЦ программ. Они должны обеспечивать эксплуатацию системы качества проекта, выявление всех отклонений от заданных показателей качества и безопасности объектов и процессов, а также от предписанной технологии на промежуточных и заключительных этапах разработки.
Для анализа затрат ресурсов в жизненном цикле ПС их целесообразно разделить на две части (Рис. 4):
· затраты на создание программных компонентов, обеспечивающих базовые свойства функциональной пригодности комплекса программ для его применения по прямому назначению пользователями в соответствии с требованиями контракта и технического задания;
· основные составляющие дополнительных затрат, обеспечивающие требуемые конструктивные характеристики качества и безопасности для улучшения функциональной пригодности ПС в соответствии с целями и сферой его применения.
Рисунок 4.
Обеспечение функциональной пригодности является основной целью при использовании финансовых, трудовых, вычислительных и других ресурсов в жизненном цикле ПС. Эти затраты зависят, в первом приближении, от сложности алгоритмов, объема комплекса программ и баз данных, которые определяют трудоемкость и длительность полного цикла их разработки. Основные затраты идут на овеществленный, преимущественно интеллектуальный труд специалистов различных категорий. Поэтому для их измерения наиболее универсальной единицей стали трудозатраты специалистов в человеко-днях или человеко-месяцах, которые обычно достаточно просто могут преобразовываться в стоимость процесса разработки [2], [6], [10]. Однако это не значит, что затраты на решение этой основной задачи всегда являются доминирующими по величине. Необходимость выполнения ряда требований к остальным конструктивным характеристикам качества и безопасности часто приводит к тому, что использование ресурсов на их реализацию может превышать базовые затраты на обеспечение функциональной пригодности. В то же время затраты на выполнение этих требований всегда направлены на повышение и совершенствование функциональной пригодности.
Абсолютная величина затрат на разработку ПС, также как и ее длительность, зависят от ряда факторов, которые могут изменять их в различных направлениях. При анализе затрат на обеспечение требуемых функций сложных ПС доминирующим фактором, влияющим на их величину, является сложность функциональной части комплекса программ и базы данных. Наиболее активно в качестве простейшего показателя сложности используется объем программ, выраженный числом операторов (команд) или строк текста на языке программирования (с учетом коэффициента, зависящего от класса ПС и специфики языка). Объем программ, без комментариев, является одной из наиболее достоверно измеряемых характеристик сложности ПС и достаточно адекватен экономическим затратам на его разработку. Реальное изменение создаваемых в настоящее время новых сложных ПС объемом от 103 до 106 строк определяет диапазон трудоемкости разработки таких программ от человеко-года до тысяч человеко-лет.
Ограниченные ресурсы времени реализации проектов ПС являются одним из самых сильных факторов, влияющих на достижимое качество и безопасность комплексов программ. При реальном допустимом времени реализации проекта оно ограничивает затраты на все промежуточные этапы работ и тем самым на качество их выполнения. При современных технологиях полностью новые, сложные комплексы программ, реализуемые в допустимое время 2—4 года, ограничены объемом 106—107 строк текста. Очевидна принципиальная нерентабельность разработки очень сложных ПС за 5—10 лет. С другой стороны, даже относительно небольшие программы высокого качества в несколько тысяч строк по полному технологическому циклу с сертификационными испытаниями продукции редко создаются за время, меньшее, чем полгода — год. Таким образом, диапазон вариации длительностей разработок ПС много меньше, чем вариация их трудоемкости, а эти длительности ограничены сверху и снизу, и объем новых программ является одним из основных факторов, определяющим эти границы.
Любые ПС должны поступать на эксплуатацию, сохраняя актуальность до того, как в них пропадает необходимость. Их цели, концептуальная основа и алгоритмы не должны устареть за время разработки. Отсюда появляется верхний предел допустимых длительностей разработки. Стремление заказчиков ограничивать длительность реальных разработок ПС приводит к объективному формированию ее верхнего предела (2 — 4 года), зависящего в основном от объема и класса ПС, за которым распространяется зона "нерациональных" длительностей.
Границу длительностей снизу определяют естественный технологический процесс коллективной разработки и необходимость выполнения ряда взаимоувязанных работ на последовательных этапах, которые обеспечивают получение сложных ПС требуемого качества. Подготовка текстов программ, их тестирование, комплексирование, документирование и испытания могут проводиться в основном последовательно, и каждый этап требует некоторого времени. Под воздействием перечисленных факторов формируется объективный минимум возможных длительностей разработок — граница снизу области "невозможных" длительностей, зависящая в первую очередь от объема разрабатываемых ПС. Эта граница может варьироваться в небольших пределах (1 — 2 года для сложных ПС) за счет: совершенствования технологии, повышения программной и аппаратурной оснащенности разработки, а также вследствие роста коллективной квалификации разработчиков и заказчиков.
Основные составляющие дополнительных затрат, обеспечивающих требуемые характеристики функциональной безопасности и качества ПС, целесообразно структурировать в соответствии с их номенклатурой в стандарте ISO 9126. Эти затраты обычно состоят из двух связанных частей: из затрат на реализацию соответствующих характеристик качества в программных продуктах и из затрат при использовании этих характеристик в процессе эксплуатации комплекса программ. Важнейшее значение имеет установление и формализация исходных требований к характеристикам качества и безопасности ПС. Поэтому целесообразно выделять ресурсы на системный анализ и проектирование требований ко всему комплексу характеристик безопасности и качества на начальных этапах проекта ПС. Обычно совершенствование качества и повышение затрат на реализацию характеристик способствует снижению затрат при их эксплуатации.
Затраты ресурсов на обеспечение корректности зависят от полноты прослеживания реализации требований к ПС сверху вниз, от требований к компонентам вплоть до объектного кода программ и от степени их покрытия тестами. Эти затраты входят непосредственно в процесс разработки и зависят от объема и детальности процессов верификации и тестирования. Для сложных ПС при требовании их высокой корректности они могут составлять до 30% от затрат на обеспечение базовой, функциональной пригодности. Для относительно простых комплексов программ эта величина в среднем составляет 10—20%. Эти затраты приходятся на верификацию и тестирование программных компонентов, что должно обеспечивать корректность, безопасность ПС и надежность в целом. Хотя эти характеристики различаются, затраты на их реализацию полностью разделить невозможно. Поэтому оценивание и выделение ресурсов на решение этих задач целесообразно анализировать совместно.
Затраты на квалификационное тестирование и испытания ПС в целом обычно могут быть достаточно четко выделены из остальных затрат, так как в этих процессах непосредственно участвуют заказчик и пользователи. Величина этих затрат без учета ресурсов, необходимых для имитации внешней среды, может составлять около 10% от общих затрат на разработку. При этом практически невозможно разделять затраты на оценивание отдельных стандартизированных характеристик.
Затраты на функциональную безопасность и надежность ПС определяются требуемым уровнем защищенности и сложностью (объемом) программ для ее реализации. При наличии особенно высоких требований к безопасности критических ПС эти затраты могут даже в 2 — 3 раза превышать затраты на решение базовых, функциональных задач. Для типовых систем трудоемкость создания программных средств функциональной безопасности обычно составляет 20 — 40% затрат на решение основных, функциональных задач при требованиях наработки на отказ в десятки тысяч часов и для минимального обеспечения автоматического рестарта в системах.
Возможные затраты трудовых и временных ресурсов на развитие и совершенствование качества и безопасности комплекса программ в процессе сопровождения зависят не только от внутренних свойств программ, но также от запросов и потребностей пользователей на новые функции и от готовности заказчика и разработчика удовлетворить эти потребности. Величина этих затрат определяется рыночной конъюнктурой для данного программного продукта и коммерческой целесообразностью его модификации и развития. По объему предполагаемых изменений, а также вновь вводимых в очередную версию компонентов, с учетом сложности и новизны их разработки могут быть оценены затраты на их создание.
Затраты на обеспечение и реализацию сопровождения программ определяются длительностью цикла жизни комплекса программ, его мобильностью, уровнем автоматизации технологии разработки и тиражом программ. Для их оценивания, прежде всего, необходимо выделять основные виды затрат при сопровождении конкретного комплекса программ и наиболее существенные факторы, которые на них влияют. Сокращение затрат на сопровождение возможно за счет некоторого увеличения затрат при разработке ПС, так что при рациональном проектировании в сумме затраты могут быть уменьшены иногда весьма заметно. Затраты на сопровождение можно считать аддитивными и включающими составляющие:
· затраты на обнаружение и устранение ошибок и дефектов в каждой версии ПС;
· затраты на доработку и совершенствование программ, формирование и испытание новых модернизированных версий ПС;
· затраты на тиражирование каждой новой версии и ее внедрение в эксплуатируемых и новых ПС.
В современных проектах ПС большую или меньшую долю составляют готовые апробированные компоненты из других подобных разработок — прототипы и/или покупные пакеты прикладных программ. Это позволяет значительно ускорять работы и сокращать затраты на создание сложных комплексов программ. Перед разработчиками проекта ПС зачастую возникает дилемма: разрабатывать ли весь комплекс программ (в том числе для обеспечения безопасности) полностью из новых компонентов или использовать, адаптировать и приспосабливать готовые компоненты (какие и в каком количестве). В результате при первичном экономическом анализе затрат на создание ПС с требуемыми характеристиками безопасности целесообразно рассматривать два альтернативных варианта определения затрат на разработку:
· полностью нового ПС, для которого отсутствуют или недоступны подходящие готовые компоненты — прототипы и/или их заведомо нерентабельно использовать;
· программного средства на базе комплексирования набора готовых программных компонентов и информации баз данных, для которого почти не требуется создания новых компонентов.
При сборке нового ПС из комплектующих компонентов может потребоваться доработка некоторых из них или создание специальных программ для их взаимодействия. В пределе при построении нового ПС на 80—90% из готовых компонентов суммарные затраты могут сокращаться в 3—5 раз. В этом случае кроме 10—20% затрат на создание новых программных компонентов, необходимы ресурсы на комплексирование нового ПС, его квалификационное тестирование, испытания и документирование.
При создании сложных ПС одной из больших составляющих затрат могут быть ресурсы на генерацию тестов. В ряде случаев они соизмеримы с затратами на создание основных функций комплексов программ (в том числе для обеспечения безопасности), что определяется принципиальным соответствием сложности необходимых наборов тестов и тестового покрытия программ, и сложности функций, реализуемых испытываемым ПС. Создание представительных совокупностей тестов возможно путем использования реальных объектов внешней среды или с помощью программных имитаторов, адекватных этим объектам по результатам функционирования и генерируемой информации. При этом возникает проблема — какой метод и когда выгодней по затратам на генерацию тестов и по обеспечению необходимой степени покрытия тестами испытываемых ПС. Затраты ресурсов на натурные эксперименты для генерации тестов при проведении разработки, испытаний и определения качества пропорциональны реальному времени функционирования проверяемого ПС и затратам на применение привлекаемых средств реальной внешней среды. Они включают стоимость эксплуатации реального объекта, создающего тесты в единицу времени.
Имитаторы тестов необходимы не только для оценивания достигнутых характеристик безопасности и качества комплексов программ, но также для их комплексной отладки, квалификационного тестирования, испытаний при создании версий. Поэтому затраты на программные имитаторы и их экономическую эффективность целесообразно рассматривать с учетом всего комплекса задач, которые они способны и должны решать в ЖЦ ПС. Затраты на программную имитацию тестовых данных определяются ресурсами, необходимыми на проектирование и эксплуатацию сложных комплексов программ для этих целей и следующими составляющими:
· затратами на разработку комплекса программ для имитации информации внешних объектов и среды их функционирования;
· затратами на эксплуатацию программ имитации за время проведения тестирования, испытаний и/или определения характеристик безопасности и качества тестируемого ПС;
· затратами на первичную установку и эксплуатацию моделирующей ЭВМ и вспомогательного оборудования, используемого в имитационном стенде.
Затраты на эксплуатацию программ имитации в основном определяются длительностью проведения тестирования, испытаний и/или измерения характеристик безопасности и качества ПС. Значения этого времени соответствуют реальному времени генерации тестовых данных и тестирования программ. Обычно имитаторы используются для тестирования нескольких ПС разного, но близкого целевого назначения. В результате удельные затраты на их создание и эксплуатацию быстро убывают при унификации имитаторов и расширении области их применения для тестирования и оценивания качества большого числа ПС, имеющих близкое функциональное назначение. Даже приближенные оценки этих затрат в большинстве случаев показывают высокую рентабельность программных имитаторов внешней среды, особенно для квалификационного тестирования и оценивания характеристик безопасности сложных ПС реального времени.