Риски в жизненном цикле сложных программных средств

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

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

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

Процессы анализа и сокращения рисков должны сопутствовать ос­новным этапам разработки и обеспечения ЖЦ сложных программных средств в соответствии с международными стандартами, а также методам систем обеспечения качества ПС. Эти процессы могут быть отражены пятью этапами работ и процедур, которые рекомендуется выполнять при поддержке базовых работ жизненного цикла проектов сложных про­граммных средств, и могут служить основой для разработки соответству­ющих планов работ при управлении и сокращении рисков — рис. 10.3:

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

— для управления рисками и их сокращения в рассматриваемых про­ектах сложных комплексов программ рекомендуется выделять три класса рисков: функциональной пригодности ПС, конструктивных характерис­тик качества и нарушения ограничений ресурсов при реализации процес­сов ЖЦ ПС;

— в каждом классе предлагается анализировать несколько категорий наиболее важных рисков, которые упорядочивать по степени опасности, угроз для проекта, обусловленных ограничениями ресурсов, дефектами и/ или недостаточным качеством разработки и жизненного цикла ПС;

— контрмеры для сокращения рисков рекомендуется анализировать и применять последовательно, начиная с ликвидации наиболее опасных исходных причин — угроз, затем проводить анализ и уменьшение уязви­мости компонентов и ПС в целом, а при недостаточности этих контрмер воздействовать непосредственно на уменьшение итогового ущерба — рис­ка в жизненном цикле ПС и системы;

— процессы устранения рисков должны завершаться процедурами мониторинга, сопровождения и конфигурационного управления измене­ниями версий комплексов программ высокого качества с минимальными допустимыми рисками.

Таким образом, в жизненном цикле программных средств ущерб — риски могут проявляться — рис. 10.4:

— в искажениях или неполной реализации требуемого назначения, функций или взаимодействия ПС с компонентами системы или внешней среды — недостатками и дефектами функциональной пригодности ком­плексов программу

— в недостаточных и не соответствующих требованиям конструк­тивных характеристиках качества ПС при его функционировании и применении по прямому назначению;

— в нарушениях ограничений на использование экономических, вре­менных или технических ресурсов при создании и применении ПС.

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

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

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

— бюджете и трудоемкости разработки и обеспечения всего жиз­ненного цикла программного продукта;

— затратах времени и сроках создания и всего жизненного цикла реализации и применения ПС;

— потребности в численности и квалификации специалистов-раз­работчиков для реализации проекта и создания программного продукта в соответствии с требованиями заказчика.

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

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

Риски ПС могут проявляться в процессах проектирования, разработ­ки и сопровождения при изменении и развитии комплексов программ и при применении готового программного продукта по прямому назначе­нию. Это приводит к необходимости анализа рисков функционирования ПС в условиях, различающихся:

— источниками и причинами угроз и опасного проявления рисков;

— классами, категориями, уязвимостью ПС и системы, вероятнос­тью проявления и величиной последствий рисков;

— возможными и реализуемыми контрмерами для сокращения рис­ков и их эффективностью.

Оценка и измерение рисков во многих случаях характеризуется зна­чительной неопределенностью и применением качественных метрик. Фак­торы и угрозы рисков могут быть распределены, и отличаться уязвимос­тью по этапам жизненного цикла ПС и системы. При анализе и управле­нии рисками целесообразно выделять, прежде всего, наиболее характерные этапы ЖЦ ПС: технико-экономическое обоснование проекта ПС; разра­ботку требований спецификаций; проектирование; кодирование; тестиро­вание и документирование.

Неопределенность оценок масштаба комплексов и компонентов про­грамм является одним из важнейших факторов, влияющим на риски всего жизненного цикла проекта ПС (см. лекцию 5).

Точность оценки размера нового ПС значительно повышается после формулирования начальных требований и спецификаций заказчиков, проведения анализа требований после завершения разработки предварительного проекта. На этапе концеп­ции проекта ошибки оценки размера ПС уменьшаются приблизительно до 40%. Это вполне объяснимо, поскольку еще не уточнены структура и многие детали проекта. Эти вопросы могут быть разрешены во время разработки структуры и спецификаций требований к ПС, и тогда можно оценить размер ПС с точностью до 15—20%.

Как только структура ПС будет разбита с учетом выделения самых нижних, доступных уровней компонентов, может быть создан более точ­ный показатель размера комплекса программ. При этом используются про­цессы измерения и суммирования. После завершения разработки и подтвер­ждения проектных спецификаций при детальном проектировании комп­лекса программ может быть определена структура внутренних данных и функции программных компонентов. На этом этапе оценка размера про-екта ПС может составить около 10%. Уточнения размеров ПС и компо­нентов могут быть решены к концу детального проектирования, однако при этом сохраняется неопределенность оценки размера комплекса про­грамм около 5—10%, связанная с тем, насколько хорошо программисты понимают спецификации, в соответствии с которыми они должны кодиро­вать программу.

В рассматриваемом ниже примере проекта ПС средние ошибки оце­нивания масштаба могут быть больше или меньше реальных значений, что по-разному отражается на характеристиках договора с заказчиком на проект, а также на факторах и типах рисков — рис. 10.5. Если масштаб проекта ПС в договоре завышен, то следствием могут быть, прежде всего, риски — ущерб экономических категорий — превышения планируемых ресурсов: стоимости, трудоемкости, длительности разработки и числа не­обходимых специалистов. При этом заказчик терпит убытки, разработчик получает неоправданную прибыль. При реализации функциональной при­годности и конструктивных характеристик ПС разработчик может свобод­но использовать ресурсы и не предпринимать жестких мер для их эконо­мии, что может отразиться на эффективности последующего применения комплекса программ.

Если при оценке масштаба проекта ПС его величина в договоре опре­делена недостаточной — заниженной, то основной ущерб — риски достаются разработчикам. Они вынуждены принимать жесткие меры для выполнения плановых сроков, выделенного бюджета работ при относи­тельно малом числе специалистов, что угрожает рисками срыва сроков и нарушения стоимости проекта. Недооценка размера проекта комплекса программ и ресурсов для его реализации может резко увеличивать число дефектов в программах. Кроме того, ограниченные ресурсы для реализа­ции в полном объеме функциональной пригодности могут отражаться на ее качестве и удобстве применения, а также на конструктивных характе-ристиках: на безопасности, надежности, качестве взаимодействия с внеш­ней средой и с пользователями, качестве документации и других эксплуа­тационных факторах.Оценки масштаба проекта ПС и рисков должны быть проанализиро­ваны и скорректированы для установления в договоре между заказчиками и разработчиками исходного компромиссного масштаба, допустимого для разработки первичных спецификаций требований с требуемым качеством.

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