Средства

Интегрального риска проекта программного

Балансирование составляющих и сокращение

Оценивание и упорядочивание приоритетов рисков проекта программного средства

Программного средства программного средства средства

I пригодности I I характеристик I проекта программного I

Функциональной конструктивных ограничений ресурсов

I Риски реализации I I Риски реализации I I Риски выполнения

Требования и угрозы к программному средству системы

Требования, угрозы и риски внешней среды Требования, угрозы и риски системы

+

_______ *i* ________

_______________ j____________

Рис. 10.4 278


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

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

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

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

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

Одной из самых распространенных причин и опасных источников рисков являются ошибки при оценке масштабаразмера проекта или


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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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


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


Оценки размера -



Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: