Это ошибки документации и фиксирования программ в памяти эвм

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

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

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

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

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

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

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

j

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

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

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

средства

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

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

Как использовать журнал событий в Windows

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

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

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

Исправляем все ошибки в Windows 10 в 2 клика.

• бюджетеи трудоемкостиразработки и обеспечения всего жизненного цикла программного продукта;
• затратах времени и срокахсоздания и всего жизненного цикла реализации и применения ПС;
• потребности в численности и квалификацииспециалистов-разработчиков для реализации проекта и создания программного продукта в соответствии с требованиями заказчика.

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

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

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

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

• источниками и причинами угроз и опасного проявления рисков;
• классами, категориями, уязвимостью ПС и системы, вероятностью проявления и величиной последствий рисков;
• возможными и реализуемыми контрмерами для сокращения рисков и их эффективностью.

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

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

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

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

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

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

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

— масштаба проекта комплекса программ

Расчет исходных значений: трудоемкости, длительности и числа специалистов для реализации комплекса программ

Оценки масштаба и исходные параметры в договоре завышены

Оценки масштаба и исходные параметры в договоре занижены

Ущерб — риски заказчика; завышены параметры:

• стоимость — трудоемкость;
• сроки — длительность;
• численность специалистов;
• ресурсы для функциональной пригодности

Ущерб — риски разработчика; занижены параметры:

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

Установлены допустимые риски,

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

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

• 284
• — при детальном проектировании — подробные спецификации требований к функциональным и конструктивным характеристикам качества с детальным учетом и распределением реальных ограниченных

Продолжение:

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.

Источник: intellect.icu

10.2. Причины и свойства дефектов, ошибок и модификаций в сложных программных средствах

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

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

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

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

Источник: studfile.net

Типичные ошибки в программных комплексах

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

¨ оценивать реальное состояние проекта и планировать трудо­емкость и длительность до его завершения;

¨ рассчитывать необходимую эффективность средств оператив­ной защиты от невыявленных первичных ошибок;

¨ оценивать требующиеся ресурсы ЭВМ по памяти и произво­дительности с учетом затрат на устранение ошибок;

¨ проводить исследования и осуществлять адекватный выбор показателей сложности компонентов и КП, а также некоторых других показателей качества.

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

Технологические ошибки документации и фикси­рования программ в памяти ЭВМ составляют 5 . 10 % от общего числа ошибок, обнаруживаемых при отладке. Большинство технологических ошибок выявляется автоматически формализо­ванными методами. При ручной подготовке машинных носителей при однократном фиксировании исходные данные имеют вероятность искажения около 10 -3 на символ или 10 -4 на двоичный разряд. Дублированной подготов­кой и логическим контролем вероятность технологической ошиб­ки может быть снижена до 10 -5 . 10 -7 на символ. Селектирую­щие свойства человека при работе с текстом из символов харак­теризуются вероятностью пропуска ошибки около 10 -3 . 10 -4 на символ. Многократный перекрестный контроль соответствия дан­ных в ЭВМ исходным документам позволяет доводить в отдельных случаях вероятность технологической ошибки в программе до уровня 10 -7 . 10 -8 .

Программные ошибки по количеству в пер­вую очередь определяются степенью автоматизации программи­рования и глубиной формализованного контроля текстов про­грамм. Количество программных ошибок зависит от квалифика­ции разработчиков, от общего объема комплекса программ, от глубины логического и информационного взаимодействия моду­лей и от ряда других факторов. На начальных этапах раз­работки и автономной отладки модулей программные ошибки составляют около 1/3 всех ошибок. На этапах комплексной отладки и эксплуа­тации удельный вес программных ошибок падает и составляет около 15 и 3 % соответственно от общего количества ошибок, выявляемых в единицу времени.

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

К алгоритмическим ошибкам следует отнести также ошибки связей модулей и функциональных групп программ. Этот вид ошибок составляет 6 . 8 % от общего количества, их можно квалифицировать как ошибки некорректной постановки задач. Алгоритмические ошибки проявляются в неполном учете диапа­зонов изменения переменных, в неправильной оценке точности используемых и получаемых величин, в неправильном учете связи между различными переменными, в неадекватном представлении формализованных условий решения задачи в спецификациях или схемах, подлежащих программированию, и т. д.

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

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

При автономной и в начале комплексной отладки доля си­стемных ошибок невелика (около 10%), но она существенно возрастает (до 35. 40 %) на завершающих этапах комплексной отладки. В процессе эксплуатации системные ошибки являются преобладающими (около 80 % от всех ошибок).

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

Задачи отладки программ

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

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

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

тестирование программы с ее исполнением в объектном ко­де и с разными уровнями детализации: детерминированное, стохастическое и тестирование в реальном времени;

диагностику и локализацию причин отклонения результатов тестирования от заданных эталонных значений или правил; изменение программы с целью исключения причин отклонения результатов от эталонных.

Основным методом обнаружения ошибок при отладке прог­рамм является их тестирование.

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

Программы, как объекты тестирования, имеют ряд особен­ностей, которые отличают процесс тестирования от традиционно­го, применяемого для проверки аппаратуры и других техничес­ких изделий. Для сложных КП практически всегда отсутствует полностью определенный и точный эталон для всех тестовых наборов. В связи с этим для тестирования в качестве эталонов используется ряд косвенных данных, которые не полностью отражают функции и характеристики отлаживаемых программ.

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

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

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

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

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

Методы разработки тестов

Источник: lektsia.com