Рисунок 2 – последствия и результаты
проявления некоторых внутренних дефектов.
Системные ошибки в большом (сложном) программном обеспечении определяются, прежде всего неполной информацией о реальных процессах, происходящих в источниках и потребителях информации. На начальных стадиях проектирования программного обеспечения не всегда удается точно сформулировать целевую задачу всей системы и требования к ней. В процессе проектирования целевая функция системы уточняется и выявляются отклонения от уточненных требований, которые могут квалифицироваться как системные ошибки. Некачественное определение требований к программе приводит к созданию программы, которая будет правильно решать неверно сформулированную задачу. В таких случаях, как правило, требуется полное перепрограммирование. Признаком того, что создаваемая для заказчика программа может оказаться не соответствующей его истинным потребностям, служит ощущение неясности задачи. Письменная регистрация требований к программе заставляет заказчика собраться с мыслями и дать достаточно точное определение требований. Всякие устные указания являются заведомо ненадежными и часто приводят к взаимному недопониманию. При автономной и в начале комплексной отладки программного обеспечения доля найденных системных ошибок в нем невелика (примерно 10%), но она существенно возрастает (до 35—40%) на завершающих этапах комплексной отладки. В процессе эксплуатации преобладающими являются системные ошибки (примерно 80% всех ошибок). Ошибки в выборе алгоритма. Часто плохой выбор алгоритма становится очевидным лишь после его опробования. Поэтому все же следует уделять внимание и время выбору алгоритма, с тем, чтобы впоследствии не приходилось переделывать каждую программу. Во избежание выбора некорректных алгоритмов, необходимо хорошо ознакомиться с литературой по своей специальности. К алгоритмическим ошибкам следует отнести, прежде всего, ошибки, обусловленные некорректной постановкой функциональных задач, когда в спецификациях не полностью оговорены все условия, необходимые для получения правильного результата. Эти условия формируются и уточняются в значительной части в процессе тестирования и выявления ошибок в результатах функционирования программ. Также следует отнести ошибки связей модулей и функциональных групп программ. Их можно квалифицировать как ошибки некорректной постановки задачи. Алгоритмические ошибки проявляются в неполном учете диапазонов изменения переменных, в неправильной оценке точности используемых и получаемых величин, в неправильном учете связи между различными переменными, в неадекватном представлении формализованных условий решения задачи в спецификациях или схемах, подлежащих программированию и т.д. Эти обстоятельства являются причиной того, что для исправления каждой алгоритмической ошибки приходится изменять иногда целые ветви программного обеспечения, т.е. пока еще существенно больше операторов, чем при исправлении программных ошибок. Алгоритмические ошибки значительно труднее поддаются обнаружению методами формализованного автоматического контроля. Вот почему необходимо тщательным образом продумывать алгоритм прежде, чем транслировать его в программу. Некоторые программисты проверяют алгоритм следующим образом. Через несколько дней после составления алгоритма они повторно обращаются к описанию задачи и составляют алгоритм заново. Затем сличают оба варианта. Такой шаг на первый взгляд может показаться пустой тратой времени, однако всякая ошибка на уровне алгоритма может в дальнейшем обернуться катастрофой и повлечь основательный пересмотр программы. Технологические ошибки— это ошибки документации и фиксирования программ в памяти ЭВМ. Они составляют 5—10 % от общего числа ошибок, обнаруживаемых при отладке. Большинство технологических ошибок выявляются автоматически формализованными методами (например, транслятором). Программные ошибки. Языки программирования — это искусственные языки, созданные человеком для описания алгоритмов. Все предложения таких языков строятся по строгим синтаксическим правилам, обеспечивающим однозначное их понимание, что позволяет поручать расшифровку алгоритма ЭВМ, построенного по правилам семантики. Синтаксис — это набор правил построения из символов алфавита специальных конструкций, с помощью которых можно составлять различные алгоритмы (программы). Эти правила требуют их неукоснительного соблюдения. В противном случае будет нарушен основной принцип — четкая и строгая однозначность в понимании алгоритма.
Семантика языка — это система правил истолкования построений конструкций. Правила семантики конструкций обычно вполне естественны и понятны, но в некоторых случаях их надо специально оговаривать, комментировать. Таким образом, программы, позволяющие однозначно производить процесс переработки данных, составляются с помощью соединения символов из алфавита в предложения в соответствии с синтаксическими правилами, определяющими язык, с учетом правил семантики. Выделяют синтаксические и семантические ошибки. Под синтаксическими ошибками понимается нарушение правил записи программ на данном языке программирования. Они выявляются самой машиной, точнее транслятором, вовремя перевода записи алгоритма на язык машины. Исправление их осуществляется просто — достаточно сравнить формат исправляемой конструкции с синтаксисом в справочнике и исправить его. Семантические (смысловые) ошибки — это применение операторов, которые не дают нужного эффекта (например, а—вместо, а+в), ошибка в структуре алгоритма, в логической взаимосвязи его частей, в применении алгоритма к тем данным, к которым он неприменим и т.д. Правила семантики не формализуемы. Поэтому поиск и устранение семантической ошибки и составляет основу отладки. Каждая программная ошибка влечет за собой необходимость изменения команд существенно меньше, чем при алгоритмических и системных ошибках. На этапах комплексной отладки программного обеспечения и эксплуатации удельный вес программных ошибок падает и составляет примерно 15 и 30 % соответственно от общего количества ошибок, выявляемых в единицу времени.
Процесс управления разработкой программного обеспечения
Невозможно описать и стандартизировать все работы, выполняемые в проекте по созда- нию ПО. Эти работы весьма существенно зависят от организации, где выполняется разработка
ПО, и от типа создаваемого программного продукта. Но всегда можно выделить следующие:
58
Написание предложений по созданию ПО.
Планирование и составление графика работ по созданию ПО.
Оценивание стоимости проекта.
Подбор персонала.
Контроль за ходом выполнения работ.
Написание отчетов и представлений.
Первая стадия программного проекта может состоять из написания предложений по ре- ализации этого проекта. Предложения должны содержать описание целей проектов и способов их достижения. Они также обычно включают в себя оценки финансовых и временных затрат на выполнение проекта. При необходимости здесь могут приводиться обоснования для передачи проекта на выполнение сторонней организации или команде разработчиков.
Написание предложений — очень ответственная работа, так как для многих организаций вопрос о том, будет ли проект выполняться самой организацией или разрабатываться по кон- тракту сторонней компанией, является критическим. Не существует каких-либо рекомендаций по написанию предложений, многое здесь зависит от опыт.
На этапе планирования проекта определяются процессы, этапы и полученные на каждом из них результаты, которые должны привести к выполнению проекта. Реализация этого плана приведет к достижению целей проекта. Определение стоимости проекта напрямую связано с его планированием, поскольку здесь оцениваются ресурсы, требующиеся для выполнения плана.
Контроль за ходом выполнения работ (мониторинг проекта) — это непрерывный про- цесс, продолжающийся в течение всего срока реализации проекта. Руководитель должен посто- янно отслеживать ход реализации проекта и сравнивать фактические и плановые показатели выполнения работ с их стоимостью. Хотя многие организации имеют механизмы формального мониторинга работ, опытный руководитель может составить ясную картину о стадии развитии проекта просто путем неформального общения с разработчиками.
Неформальный мониторинг часто помогает обнаружить потенциальные проблемы, ко- торые в явном виде могут обнаружиться позднее. Например, ежедневное обсуждение хода вы- полнения работ может выявить отдельные недоработки в создаваемом программном продукте.
Вместо ожидания отчетов, в которых будет отражен факт «пробуксовки» графика работ, можно обсудить со специалистами намечающиеся программистские проблемы и не допустить срыва графика работ.
В течение реализации проекта обычно происходит несколько формальных контрольных проверок хода выполнения работ по созданию ПО. Такие проверки должны дать общую кар- тину хода реализации проекта в целом и показать, насколько уже разработанная часть ПО со- ответствует целям проекта.
Время выполнения больших программных проектов может занимать несколько лет. В течение этого времени цели и намерения организации, заказавшей программный проект, могут существенно измениться. Может оказаться, что разрабатываемый программный продукт стал уже ненужным либо исходные требования к создаваемому ПО просто устарели и их необхо- димо кардинально менять. В такой ситуации руководство организации-разработчика может принять решение о прекращении разработки ПО или об изменении проекта в целом с тем, чтобы учесть изменившиеся цели и намерения организации-заказчика.
Руководители проектов обычно обязаны сами подбирать исполнителей для своих проек- тов. В идеальном случае профессиональный уровень исполнителей должен соответствовать той работе, которую они будут выполнять в ходе реализации проекта. Однако во многих случаях руководители должны полагаться на команду разработчиков, которая далека от идеальной. Та- кая ситуация может быть вызвана следующими причинами:
1. Бюджет проекта не позволяет привлечь высококвалифицированный персонал. В таком случае за меньшую плату привлекаются менее квалифицированные специалисты.
59 2. Бывают ситуации, когда невозможно найти специалистов необходимой квалификации как в самой организации-разработчике, так и вне ее. Например, в организации «лучшие люди» могут быть уже заняты в других проектах.
3. Организация хочет повысить профессиональный уровень своих работников. В этом слу- чае она может привлечь к участию в проекте неопытных или недостаточно квалифици- рованных работников, чтобы они приобрели необходимый опыт и поучились у более опытных специалистов.
Таким образом, почти всегда подбор специалистов для выполнения проекта имеет опре- деленные ограничения и не является свободным. Вместе с тем необходимо, чтобы хотя бы не- сколько членов группы разработчиков имели квалификацию и опыт, достаточные для работы над данным проектом. В противном случае невозможно избежать ошибок в разработке ПО.
Руководитель проекта обычно обязан посылать отчеты о ходе его выполнения как заказ- чику, так и подрядным организациям. Это должны быть краткие документы, основанные на информации, извлекаемой из подробных’ отчетов о проекте. В этих отчетах должна быть та информация, которая позволяет четко оценить степень готовности создаваемого программного продукта.
В рамках курса «Технология разработки программного обеспечения» выделены следу- ющие роли в группе по разработке ПО:
Руководитель – общее руководство проектом, написание документации, общение с за- казчиком ПО
Системный аналитик – разработка требований (составление технического задания, про- екта программного обеспечения)
Тестер – составление плана тестирования и аттестации готового ПО (продукта), состав- ление сценария тестирования, базовый пример, проведение мероприятий по плану те- стирования
Разработчик – моделирование компонент программного обеспечения, кодирование
Планирование проекта разработки программного обеспечения
Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения. План помогает руководителю предви- деть проблемы, которые могут возникнуть на каких-либо этапах создания ПО, и разработать превентивные меры для их предупреждения или решения. План, разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий документ, выполне- ние которого должно привести к успешному завершению проекта. Этот первоначальный план должен максимально подробно описывать все этапы реализации проекта.
Процесс планирования начинается, исходя из описания системы, с определения проект- ных ограничений (временные ограничения, возможности наличного персонала, бюджетные ограничения и т.д.). Эти ограничения должны определяться параллельно с оцениванием про- ектных параметров, таких как структура и размер проекта, а также распределением функций среди исполнителей. Затем определяются этапы разработки и то, какие результаты документа- ция, прототипы, подсистемы или версии программного продукта) должны быть получены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала разраба- тывается график работ по выполнению проекта или дается разрешение на продолжение исполь- зования ранее созданного графика. После этого проводится контроль выполнения работ и от- мечаются расхождения между реальным и плановым ходом работ.
Далее, по мере поступления новой информации о ходе выполнения проекта, возможен пересмотр первоначальных оценок параметров проекта. Это, в свою очередь, может привести к изменению графика работ. Если в результате этих изменений нарушаются сроки завершения проекта, должны быть пересмотрены (и согласованы с заказчиком ПО) проектные ограничения.
Конечно, большинство руководителей проектов не думают, что реализация их проектов прой- дет гладко, без всяких проблем. Желательно описать возможные проблемы еще до того, как они проявят себя в ходе выполнения проекта. Поэтому лучше составлять «пессимистические» гра- фики работ, чем «оптимистические». Но, конечно, невозможно построить план, учитывающий
60 все, в том числе случайные, проблемы и задержки выполнения проекта, поэтому и возникает необходимость периодического пересмотра проектных ограничений и этапов создания про- граммного продукта.
План проекта должен четко показать ресурсы, необходимые для реализации проекта, разделе- ние работ на этапы и временной график выполнения этих этапов. В некоторых организациях план проекта составляется как единый документ, содержащий все виды планов, описанных выше. В других случаях план проекта описывает только технологический процесс создания ПО.
В таком плане обязательно присутствуют ссылки на планы других видов, но они разрабатыва- ются отдельно от плана проекта.
Детализация планов проектов очень разнится в зависимости от типа разрабатываемого программного продукта и организации-разработчика. Но в любом случае большинство планов содержат следующие разделы.
1. Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, вре- менных и т.д.), которые важны для управления проектом.
2. Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды.
3. Анализ рисков. Описание возможных проектных рисков, вероятности их проявления и стратегий, направленных на их уменьшение.
4. Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень аппаратных средств и программного обеспечения, необходимого для разработки про- граммного продукта. Если аппаратные средства требуется закупать, приводится их сто- имость совместно с графиком закупки и поставки.
5. Разбиение работ на этапы. Процесс реализации проекта разбивается на отдельные про- цессы, определяются этапы выполнения проекта, приводится описание результатов
(«выходов») каждого этапа и контрольные отметки.
6. График работ. В этом графике отображаются зависимости между отдельными процес- сами (этапами) разработки ПО, оценки времени их выполнения и распределение членов команды разработчиков по отдельным этапам.
7. Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются предоставляемые руководителем отчеты о ходе выполнения работ, сроки их предостав- ления, а также механизмы мониторинга всего проекта.
План должен регулярно пересматриваться в процессе реализации проекта. Одни части плана, например, график работ, изменяются часто, другие более стабильны. Для внесения из- менений в план требуется специальная организация документопотока, позволяющая отслежи- вать эти изменения.
Ход работы
1. Составить подробное описание информационной системы.
2. На основании описания системы провести анализ осуществимости. В ходе анализа отве- тить на вопросы:
Что произойдет с организацией, если система не будет введена в эксплуатацию?
Какие текущие проблемы существуют в организации и как новая система поможет их решить?
Каким образом система будет способствовать целям бизнеса?
Требует ли разработка системы технологии, которая до этого не использовалась в орга- низации?
Результатом анализа должно явиться заключение о возможности реализации проекта.
4. Распределить роли в группе (руководитель проекта-разработчик, системный аналитик- разработчик, тестер-разработчик).
5. Заполнить разделы плана:
Введение
Организация выполнения проекта
Анализ рисков
61
Разделы должны содержать рекомендации относительно разработки системы, базовые предложения по объёму требуемого бюджета, числу разработчиков, времени и требуемому про- граммному обеспечению.
Практическая работа № 4.14. Анализ рисков
Цель работы: анализ рисков информационной системы\
Теоретический материал
1 Идентификация рисков
1.1 Риск утери информации о клиентах риск информационный потеря безубыточность
Так как внедрено программное обеспечение, в котором хранится вся информация о кли- ентах и данных компании, имеется риск потери этих данных, несанкционированный доступ к ним, вследствие чего возможна кража конфиденциальной информации о клиентах, а так же блокировка абонементов, что понесет существенные убытки компании.
Данный риск относится к информационным рискам. В результате воздействия этого со- бытия на обрабатываемую, хранящуюся или передаваемую информацию может произойти ее искажение, подделка, утечка, хищение, потеря, т.е. собственнику, владельцу информационных ресурсов может быть нанесен ущерб.
1.2 Риск отказа работы ПО на длительное время
Так же имеет место быть риск отказа работы ПО, что несет за собой временное отсут- ствие доступа ко всем данным, в том числе и бухгалтерским. В результате этого бухгалтер не сможет совершать никаких операций. Например, для бухгалтера будет недоступна подача дан- ных в налоговую инспекцию, что повлечет за собой начисления штрафных санкции для орга- низации, а так же может привести к лишению лицензии фитнес-клуба.
Так же, в результате воздействия этого риска, бухгалтер не сможет начислить сотрудни- кам заработную плату.
Нестабильные выплаты заработной платы портят репутацию компании и ведут к уволь- нению сотрудников.
Данный риск относится к производственным рискам, связанным с убытками от оста- новки производства или коммерческой деятельности либо предоставления услуг в сфере ин- форматизации вследствие воздействия различных факторов, прежде всего, связанных с утратой или повреждением информации.
2 Оценка рисков
Оценка рисков производится по качественному и количественному методам.
Обычно считается, что риск тем больше, чем больше вероятность происшествия и тя- жесть последствий, т.е. наблюдается зависимость от двух факторов: вероятности происшествия и тяжести возможных последствий.
2.1 Риск утери информации о клиентах
Сначала необходимо определить значения шкал. Значения субъективной шкалы вероят- ностей происшествия равно C – вероятность события – около 0,5.
Значения субъективной шкалы серьезности последствий равно Mo (Moderate – умерен- ный, средний) – происшествие с умеренными результатами: ликвидация последствий не свя- зана с крупными затратами, воздействие на информационную технологию небольшое и не за- трагивает критически важных задач. По матрице результатов оценивания рисков строится гра- фик.
Ход работы
Задание 1. Общая стоимость компании составляет 2 000 000 руб. Риск утери данных мо- жет нанести ущерб с фактором воздействия 50%. Вероятность происшествия – раз в 5 лет, т.е.
0,5.
Расчет цены потерь (Q) производится по формуле 1.
62
Q = K * С,
(1)
К – Общая стоимость компании
С – фактор воздействия риска
Q = 2 000 000 * 0,5 = 1 000 000 рублей.
Величина риска (R) в данной ситуации зависит от двух факторов и считается по формуле
R = P * Q
(2)
Р – Вероятность наступления риска
R = 0,5 * 1 000 000 = 500 000 рублей, т.е. существует риск потери такой суммы ежегодно.
Задание 2. Риск потери информации в результате отказа работы ПО на длительное время
Значения субъективной шкалы вероятностей происшествия равно B – событие случается редко.
Значения субъективной шкалы серьезности последствий равно C (Critical – критический)
– происшествие приводит к невозможности решения критически важных задач.
По матрице результатов оценивания рисков строится график
Общая стоимость компании составляет 2 000 000 руб. Риск утери данных может нанести ущерб с фактором воздействия 95%. Вероятность происшествия – раз в 10 лет, т.е. 0,1.
Расчет цены потерь производится по формуле 1.
Q = 2 000 000 * 0,95 = 1 900 000 рублей.
Величина риска в данной ситуации зависит от двух факторов и считается по формуле 2.
R = 0,1 * 1 900 000 = 190 000 рублей, т.е. существует риск потери такой суммы ежегодно.
Рекомендации по минимизации рисков
Планирование рисков подразумевает их уменьшение за счет принятия некоторых мер, например, грамотное управление паролями снижает риск несанкционированного доступа
(НСД).
Для минимизации риска отказа ПО, необходима постоянная его техническая поддержка, которая производится компанией на аутсорсинге.
Если не удается уклониться от риска или эффективно его уменьшить, можно принять некоторые меры страховки, например, заключить договор с поставщиками ПО о сопровожде- нии и компенсации ущерба, вызванного нештатными ситуациями.
Практическая работа № 4.15. Выявление первичных и вторичных ошибок
Цель работы: способы выявление первичных и вторичных ошибок.
Теоретический материал
Неоднократно экспериментально установлено, что в любом сложном комплексе про- грамм в процессе эксплуатации обнаруживаются ошибки[Липаев_3], даже если проведено са- мое тщательное тестирование. Важной особенностью тестирования программ является невоз- можность получения полностью определенной абсолютно корректной программы, которую можно было бы использовать в качестве эталона без ошибок для сравнения с ней создаваемой программы. Поэтому при тестировании первоначально обнаруживаются вторичные ошибки, которые являются отклонениями некоторых результатов функционирования программ от пред- полагаемых эталонных значений. Тестирование для локализации ошибки позволяет установить причину вторичной ошибки и выявить первичную ошибку, подлежащую исправлению.
Первичные ошибки в программах в различной степени искажают результаты, которые первоначально обнаруживаются как вторичные ошибки, в процессе тестирования. Каждая пер- вичная ошибка k-го типа отражается как вторичная ошибка j-го результата с некоторым коэф- фициентом пропорциональности Dkj. Если в некоторый момент тестирования имеющиеся пер- вичные ошибки характеризуются вероятностями проявления Qk, то они будут приводить к ин- тегральным вторичным ошибкам с интенсивностью (весом), рассчитываемой как
63 где m— полное число возможных типов ошибок в программах; q— полное число контролируемых результатов, в которых могут проявляться вторичные ошибки.
Однако прямыми измерениями невозможно установить коэффициент влияния первич- ных ошибок на вторичные Dk j, а также вероятность первичных ошибок Qk. Поэтому исследо- ваны, в основном, обобщенные характеристики вторичных ошибок и некоторые общие законо- мерности проявления первичных ошибок в процессе тестирования программ.
В результате анализа и обобщения экспериментальных данных предложено несколько математических моделей, описывающих основные закономерности изменения суммарного числа вторичных ошибок в программах. Эти модели предназначены для оценки: возможного изменения надежности функционирования в процессе отладки, испытаний и эксплуатации; числа ошибок, оставшихся не выявленными в тестируемых программах; времени, требующе- гося для обнаружения следующей ошибки в функционирующей или тестируемой программе; времени, необходимого для выявления всех ошибок с заданной вероятностью.
Точное определение полного числа не выявленных ошибок в ПО прямыми методами из- мерения невозможно, поскольку в противном случае их можно было бы все зафиксировать и устранить. Однако имеются косвенные пути для приближенной статистической оценки их пол- ного числа или вероятности ошибки в каждой команде программы.
Такие оценки базируются на построении математических моделей в предположении жесткой корреляции между общим числом ошибок и их проявлениями в некотором ПО после его отладки в течение времени t, т.е. между следующими параметрами: суммарным числом первичных ошибок в ПО (n0) или вероятностью ошибки в каждой команде программы (p0): числом вторичных ошибок, выявляемых в единицу времени в процессе тестирования и отладки при постоянных усилиях на ее проведение (dn/dt); интенсивностью искажений результатов в единицу времени (l) на выходе программы
(вследствие невыявленных первичных ошибок) при функционировании системы в типовых условиях.
В результате может быть построена экспоненциальная математическая модель распре- деления ошибок в программах и установлена связь между интенсивностью обнаружения вто- ричных ошибок при тестировании dn/dt, интенсивностью l проявления ошибок при нормальном функционировании ПО и числом выявленных первичных ошибок n. При этом учитываются все виды ошибок независимо от источников их происхождения (технологические, программные, алгоритмические, системные).
При постоянных усилиях на тестирование интенсивность обнаружения искажений и вы- числительного процесса, программ или данных вследствие еще невыявленных ошибок пропор- циональна числу n0оставшихся первичных ошибок в ПО. Тогда dn/dt= К’l = Кn0=K(N0 – n), где N0— число ошибок в ПО в начале отладки, а коэффициенты К и К’ учитывают: мас- штаб времени, используемого для описания процесса обнаружения ошибок, быстродействие
ЭВМ, распределение тестовых значений на входе проверяемого комплекса программ и другие параметры. Значение коэффициента К’ можно, в принципе, определить как изменение темпа проявления ошибок при переходе от функционирования программ на специальных тестах к функционированию на нормальных типовых исходных данных. Так как предполагается, что в начале отладки при t= 0 отсутствуют обнаруженные ошибки, то n = N0 [1 – exp(-Кt)].
Число оставшихся первичных ошибок в ПО n0 = N0 exp(-Кt), пропорционально интен- сивности обнаружения dn/dt с точностью до коэффициента К.
Длительность функционирования программ (наработка) между проявлением ошибок, которые рассматриваются как обнаруживаемые искажения программ, данных или вычисли- тельного процесса, равна величине, обратной интенсивности обнаружения ошибок
64
Если известны все моменты обнаружения ошибок tiи каждый раз в эти моменты обнару- живается и достоверно устраняется одна первичная ошибка, то, используя метод максималь- ного правдоподобия, можно получить уравнение для определения значения начального числа первичных ошибок N0 а также выражение для расчета коэффициента пропорциональности
В результате можно рассчитать число оставшихся в программе первичных ошибок и среднюю наработку Т до обнаружения следующей ошибки. С помощью преобразований можно получить затраты времени на тестирование, которые позволяют устранить dn ошибок и соот- ветственно повысить наработку между очередными обнаружениями ошибок от значения Т1 до
Т2
Необходимо подчеркнуть статистический характер приведенных соотношений. Нерав- номерность выбора маршрутов исполнения программы при нормальной эксплуатации, разное влияние конкретных типов ошибок в программах на проявление их при функционировании, а также сравнительно небольшие значения n и dn, особенно на заключительных этапах отладки приводят к тому, что затраты времени на тестирование могут быть весьма значительными.
Практическая работа № 3
Тема Выявление первичных и вторичных ошибок
Цель: научиться выявлять первичные и вторичные ошибки программного обеспечения
Теоретические сведения
Под ошибкой в широком смысле слова понимается неправильность, погрешность или неумышленное, невольное искажение объекта или процесса. При этом подразумевается, что известно правильное или неискаженное эталонное состояние объекта, к которому относится ошибка.
Считается, что если программа не выполняет того, что пользователь от нее ожидает, то в ней имеется ошибка.
Важной особенностью процесса выявления ошибок в сложных программах является отсутствие полностью определенной правильной программы-эталона, которому должен соответствовать проверяемый текст.
Поэтому нельзя гарантированно утверждать, что возможно написать программу без ошибок.
Рисунок 1 – Распределение выявленных ошибок
Искажения в тексте программ (первичные ошибки) являются элементами, подлежащими корректировке. Однако непосредственно наличие ошибки обнаруживаются по ее вторичным проявлениям.
Искажение выходных результатов исполнения программ (вторичная ошибка) вызывает необходимость выполнения ряда операций по локализации устранению первичной ошибки (отладка программ).
На этапе отладки программ выявляются и исправляются много ошибок, но не все.
После отладки в течение некоторого времени интенсивность обнаружения ошибок при самом активном тестировании снижается настолько, что разработчики попадают в зону нечувствительности к программным ошибкам и отказам.
При такой интенсивности отказов программ трудно прогнозировать затраты времени, необходимые для обнаружения очередной ошибки.
Создается представление о полном отсутствии ошибок в программе, о невозможности и бесцельности их поиска. Поэтому усилия на отладку сокращаются, и интенсивность обнаружения ошибок еще больше снижается.
Этой предельно низкой интенсивности обнаружения отказов соответствует наработка на обнаруженную ошибку, при которой прекращается улучшение характеристик программного обеспечения на этапах его отладки и испытаний у заказчика.
Ошибку можно отнести к одному из ниже перечисленных классов:
системные ошибки;
ошибки в выборе алгоритма;
алгоритмические ошибки;
технологические ошибки;
программные ошибки.
Поделитесь с Вашими друзьями:
Практическая работа №1 Выявление первичных и вторичных ошибок
Цель: научиться выявлять первичные и вторичные ошибки программного
обеспечения
Ход работы:
1. Изучить теоретическую часть.
2. Разделить ошибки на первичные и вторичные
3. Заполнить таблицу “Категории тяжести ошибки в программном
обеспечении”
4. Ответить на контрольные вопросы.
✓ Приведите классификацию ошибок программного обеспечения
✓ Какие ошибки могут возникнуть при тестировании программного
обеспечения?
✓ Перечислите основные пути борьбы с ошибками.
5. Сделать отчёт по работе, представить в нём полностью 4 пункта с
ответами.
Теоретические часть.
Под ошибкой в широком смысле слова понимается неправильность,
погрешность или неумышленное, невольное искажение объекта или
процесса. При этом подразумевается, что известно правильное или
неискаженное эталонное состояние объекта, к которому относится ошибка.
Считается, что если программа не выполняет того, что пользователь
от нее ожидает, то в ней имеется ошибка.
Методы оценки профессиональных рисков
Для того чтобы сохранить жизнь и здоровье сотрудников предприятия необходимо выявлять риски на рабочем месте, применив методы оценки профессиональных рисков, оценить и внедрить управление ими.
На момент написания статьи методы оценки профессиональных рисков не утверждены ни Федеральными законами, ни постановлениями Министерств. Вместе с тем, необходимость в проведении этого мероприятия закреплена в ст. 209 и 212 Трудового кодекса РФ.
Нормативные документы по оценке профрисков
- Приказ Минтруда России от 28.12.2021 № 926 «Об утверждении Рекомендаций по выбору методов оценки уровней профессиональных рисков и по снижению уровней таких рисков»
- Приказ Минтруда России от 31.01.2022 № 36 «Об утверждении Рекомендаций по классификации, обнаружению, распознаванию и описанию опасностей»
- Приказ Минтруда России от 29 октября 2021 г. N 776н «Об утверждении примерного положения о системе управления охраной труда»
Ознакомиться с документами
Где закреплены методики оценки рисков?
Сегодня широкой публике представлены десятки способов оценить профессиональные риски: начиная с тех, что закреплены в ГОСТах и заканчивая авторскими методами экспертных организаций. Разберём, какие методы оценки профессиональных рисков подходят для определённых ситуаций, расскажем про их плюсы и минусы применения.
Отсутствие единой утверждённой методики оценки профессиональных рисков заставило работодателей искать любые зацепки в нормативной документации, строить логические догадки и перечитывать государственные стандарты. В итоге сформировался список документов, которые содержат методы оценки профессиональных рисков:
- OHSAS 18001:2007 (он же ГОСТ Р 54934-2012) «Система менеджмента безопасности охраны труда и охраны здоровья»
- OHSAS 18002:2008 «Система менеджмента безопасности и охраны здоровья. Руководство к применению»
- BS 18004:2008 «Руководство по достижению эффективности в области безопасности труда и охраны здоровья»
- ГОСТ Р 12.0.010-2009 «Система стандартов безопасности труда. Система управления охраной труда. Определение опасностей и оценка риска»
- ГОСТ 12.0.003-74 «Опасные и вредные производственные факторы. Классификация, а также нормативно-правовые акты, невыполнение которых может привести к возникновению опасных ситуаций»
- ГОСТ Р 51898-2002 «Аспекты безопасности. Правила включения в стандарты»
- ГОСТ Р ИСО/МЭК 31010-2011 «Менеджмент риска. Методы оценки риска»
Чаще стали появляться и авторские методы оценки профессиональных рисков: мы с интересом отмечаем работы Т.В. Ригера (метод коэффициента безопасности труда), С.С. Тимофеевой (совершенствование современного законодательства в области охраны труда).
Безусловно, это не окончательный список. В скором времени появится еще методы оценки профессиональных рисков, среди которых, как мы надеемся, будет единый, принятый на Федеральном уровне.
Методы оценки уровня профессиональных рисков выбираются с учётом:
- цели проведения оценки рисков;
- типа и диапазона анализируемого риска;
- возможных последствий опасного события;
- степени необходимых экспертиз, человеческих и других ресурсов (простой правильно примененный метод может обеспечить лучшие результаты, если он соответствует области применения оценки, чем сложная процедура, выполненная с ошибками);
- доступности информации и данных;
- потребности в модификации/обновлении оценки риска;
- обязательных и договорных требований.
Наиболее распространённые методы оценки уровня профессиональных рисков
Матричный метод
Наиболее распространённый метод, заключающийся в качественной оценке показателей вероятности возникновения опасных событий и тяжести их последствий. Данный метод позволяет работодателю провести оценку уровня профессиональных рисков на рабочих местах с наименьшими затратами ресурсов.
Пример расчета рисков матричным методом
Пошаговая последовательность матричного метода оценки уровня рисков:
1) Сбор информации о состоянии охраны и условий труда рабочих местах, включающий данные:
- о расположении рабочего места и/или места проведения работ;
- о работниках, выполняющих работу (следует обращать особое внимание на такие категории работников, как молодежь, беременные женщины, работники с ограниченными возможностями, подрядчики, посетители и др.);
- о применяемых оборудовании, материалах и сырье;
- о ранее выявленных опасностях;
- о принятых защитных мерах;
- о зарегистрированных несчастных случаях и профессиональных заболеваниях;
- о результатах специальной оценки условий труда;
- о законодательных и иных требованиях, предъявляемых к рабочим местам.
2) Формирование реестра опасностей по видам работ, рабочим местам, профессиям или структурным подразделениям
в зависимости от потребностей работодателя и особенностей производственных процессов конкретного предприятия.
3) Оценка вероятности и степени тяжести возможных последствий. На этом этапе
важной задачей является определение критериев степени тяжести и вероятности наступления негативного события.
4) Разработка мер по устранению опасностей и снижению уровней профессиональных рисков.
5) Документирование процедуры оценки уровня профессиональных рисков. Составляется реестр всех выявленных
опасностей. Для каждой выявленной опасности записываются:
- результаты оценки уровня профессионального риска, связанного с каждой опасностью;
- перечень мероприятий, запланированных для снижения уровней высоких и умеренных профессиональных рисков;
- предупредительные и защитные меры для низких и малозначимых профессиональных рисков.
Закажите оценку профессиональных рисков
Контрольные листы
Контрольные листы являются наиболее распространенным методом контроля уровня профессиональных рисков на малых и микропредприятиях, которые разрабатываются на основе полученного ранее опыта, включая опыт других аналогичных организаций.
Для разработки контрольного листа необходимо:
- определить производственные процессы или иную деятельность, которые необходимо контролировать;
- составить перечень требований, предъявляемых к этим процессам или производственной деятельности;
- направить контрольный лист для заполнения работникам, выполняющим данные операции.
Списки контрольных вопросов необходимо своевременно актуализировать и вносить в них дополнения согласно изменениям как производственных процессов, так и государственных нормативных требований охраны труда.
К составлению указанных списков следует привлекать специалистов службы охраны труда, которые владеют соответствующей информацией, а также привлекать работников, непосредственно связанных с исследуемыми производственными процессами на рабочих местах.
Анализ «галстук-бабочка»
Представляет собой способ описания пути развития опасного события от причин до последствий при помощи схемы. Основное внимание в методе «галстук-бабочка» уделяется мерам управления и контроля) между причинами и опасными событиями, а также опасными событиями и их последствиями.
Метод реализуется пошагово путем выполнения следующих процедур:
Шаг 1. Определение опасного события, выбранного для анализа, и отображение его в качестве центрального узла «галстука-бабочки».
Шаг 2. Составление перечня причин события с помощью исследования источников опасности, опасной ситуации.
Шаг 3. Определение и описание механизма развития опасности до критического события (тяжелой травмы, аварии, катастрофы и т. п.).
Шаг 4. Графическое проведение линии, отделяющей причину от события (центрального узла «галстука-бабочки»), что позволяет сформировать левую сторону диаграммы. Дополнительно могут быть идентифицированы и включены в диаграмму факторы, которые могут привести к эскалации (увеличению вероятности наступления события, либо повышению степени тяжести его последствий) опасного события.
Шаг 5. Нанесение на диаграмму при помощи вертикальных линий преград, соответствующих барьерам, установленным на пути причин возникновения нежелательного события.
Шаг 6. Определение и описание в правой стороне «бабочки» различных последствий опасного события и проведение линий, соединяющих центральное событие с каждым возможным последствием.
Шаг 7. Графическое изображение при помощи вертикальных линий преград барьеров для предотвращения негативных последствий.
Шаг 8. Отображение под диаграммой «галстук-бабочка» вспомогательных функций управления, относящихся к средствам управления (таких как обучение и проверки), и соединение их с соответствующим средством управления.
Анализ «затрат и выгод»
Анализ эффективности затрат используют в ситуации, когда необходимо сравнить общие ожидаемые затраты с общими ожидаемыми выгодами (доходами и преимуществами) и выбрать лучший или наиболее выгодный вариант решения. Данный метод является неявной частью многих систем оценки риска.
В начале процесса определяются все заинтересованные стороны, которые могут понести затраты или получить выгоды. В полный анализ эффективности затрат включают все заинтересованные стороны.
Далее определяют прямые и косвенные выгоды и затраты всех соответствующих заинтересованных сторон, связанных с оцениваемым риском.
Прямые выгоды — это выгоды, полученные непосредственно от предпринятых действий.
Косвенные (или вспомогательные) выгоды носят обычно случайный характер, но могут оказывать существенное влияние на решение задачи.
Примерами косвенных выгод могут быть повышение репутации, удовлетворенность персонала и улучшение психологического климата. К таким затратам также можно отнести дополнительные, вспомогательные и неокупаемые затраты, такие как потеря рентабельности, потеря времени высшего руководства организации или отвлечение капитала от других инвестиций.
Результатом применения метода является информация об относительных затратах и выгодах при различных вариантах решений или действий. Выходные данные могут быть выражены количественно в виде чистой приведенной стоимости, внутреннего коэффициента рентабельности или в виде отношения приведенной стоимости выгод к приведенной стоимости затрат. Качественно выходные данные обычно выражают в форме таблицы, в которой сопоставляют различные типы затрат и выгод.
Причинно-следственный анализ
Применение этого метода позволяет идентифицировать фактические причины.
Информацию представляют в виде диаграммы «рыбьего скелета» (метод также называют диаграммой Исикавы, используемой для измерения, оценки, контроля и усовершенствования качества производственных процессов) или в виде древовидной схемы. Метод применим для идентификации возможных причин нежелательного события.
Метод анализа сценариев
Данный метод может быть использован для описания и управления рисками путем рассмотрения возможных событий в будущем и исследования их значимости и последствий. Наборы сценариев, отражающих, например, «лучший случай», «худший случай» и «ожидаемый случай», могут быть
использованы для анализа возможных последствий и их вероятности для каждого сценария.
Метод позволяет рассматривать основные изменения в технологиях, предпочтениях потребителей и т. д. Особенностью использования данного метода является наличие группы специалистов, обладающих пониманием характера исследуемых изменений.
Метод применим при планировании будущих стратегий, а также при рассмотрении существующих видов деятельности.
Метод анализа «дерева решений»
Метод позволяет последовательно представить альтернативные варианты решений с их выходными данными с учетом соответствующей неопределенности.
Анализ начинается с заданного исходного события или принятого решения. Далее проводится прогнозирование развития событий, определяются результаты, которые могут быть получены при реализации событий, и различные решения, которые могут быть приняты.
Метод «дерева решений» применяют в управлении риском проектных решений и в других случаях, когда необходимо выбрать наилучший способ действий в ситуации неопределенности.
Метод анализа уровней защиты
Метод основан на выборе пар причин и последствий и выявлении уровней защиты, которые могут предотвратить причину, приводящую к нежелательному последствию. Для определения адекватности мер снижения риска до допустимого уровня необходимо провести расчет последствий.
Метод может быть использован как качественный метод исследования уровней защиты между опасностью или причинным событием и результатом («анализ барьеров»), а также позволяет оценить средства и меры управления и их эффективность для автоматизированных систем.
Метод технического обслуживания, направленный на обеспечение надежности
Используется для обеспечения эффективного технического обслуживания и применяется, как правило, на этапе проектирования и разработки, а затем внедряется на этапе производства и технического облуживания.
Дает возможность установить задачи в области технического обслуживания, такие как мониторинг технического состояния, плановые ремонт и замена, обнаружение отказов или текущее техническое обслуживание используемого оборудования. Дополнительные действия, которые могут быть реализованы по результатам применения рассматриваемого метода, включают в себя модернизацию используемого оборудования, внесение изменений в эксплуатационные документы и процедуры технического обслуживания этого оборудования, а также проведение дополнительного обучения работников, эксплуатирующих это оборудование. В рамках анализа также необходимо
идентифицировать периодичность выполнения задач и требуемые ресурсы.
Метод анализа первопричины
Метод представляет собой совокупность приемов и методов анализа потерь или ущерба, направленных на предотвращение их повторного возникновения, и направлен на выявление первичных причин отказа оборудования или систем без рассмотрения внешних проявлений отказа.
Метод применим:
- в области безопасности для исследования несчастных случаев в области охраны труда и производственной безопасности;
- в технологических системах для анализа надежности и технического обслуживания используют анализ отказов;
- для контроля качества производственных процессов;
- для исследования бизнес-процессов;
- при анализе сложных систем в системах управления изменениями менеджмента риска и в системном анализе (в виде комбинации перечисленных видов RCA).
Метод анализа влияния человеческого фактора
Данный метод обеспечивает формализованный способ исследования ошибок оператора при оценке риска для систем, работа которых существенно зависит от действий персонала. Оценка действий персонала позволяет выявить ошибки, которые могут отрицательно влиять на производительность, и определить способы устранения данных ошибок, а также других причин отказа систем, в том числе технических и программных средств.
Рекомендуется для оценки влияния действий работника, в том числе ошибок оператора, на работу рассматриваемой системы, а также может быть использован в целях качественной оценки действий оператора в целях идентификации его возможных ошибок и их причин, что позволяет снизить как количество таких ошибок, так и влияние последствий таких ошибок на работу рассматриваемой системы.
Кроме того, предлагаемый метод может быть использован для получения количественных данных об отказах, связанных с ошибками оператора, в качестве исходных данных для применения других методов.
Два способа оценки профрисков
Работодатель вправе разработать собственный метод оценки уровня профессиональных рисков, исходя из специфики своей деятельности.
