выаыва. Лаб_9-10-11 - характеристики сложности. Лабораторные работы 3, 4, 5 Введение
 Скачать 0.7 Mb.
|
|
1 Лабораторные работы №3, №4, №5 Введение Необходимым условием создания программного продукта, показатели качества которого удовлетворяют требованиям технического задания, является назначение обоснованных норм надежности. Следует подчеркнуть, что часто разработчики технического задания формируют необоснованные требования к показателям надежности Завышение требований к надежности приводит к необоснованным затратам на стадиях разработки программного продукта. Занижение требований к показателям надежности приводит к завышенным затратам на стадии эксплуатации изделия. Цели и задачи лабораторной работы Целью выполнения лабораторной работы является изучение моделей оценивания показателей надежности. Теоретическая часть 1. Основные понятия и определения Software Reliability Engineering (SRE) решает проблемы, источником которых являются потребности пользователей программных продуктов. SRE есть прикладное научное направление, занимающееся вопросами измерения, предсказания и управления (на тактическом уровне) надежностью систем, функциональность которых зависит от состояния входящих в их состав программных продуктов с тем, чтобы максимизировать удовлетворенность пользователей. Вопросам SRE уделяется большое внимание в таких областях как телекоммуникационные системы; системы дистанционного образования; аэрокосмическая промышленность. Высокий интерес к SRE обусловлен тем, что выбор адекватного метода управления надежностью способствует повышению качества управления проектом. К числу организаций, вкладывающих ресурсы в исследования по тематикам SRE, относятся:Alkatel, AT&T, Hewlett-Packard, Hitachi, IBM Corp, Motorola, NASA, US Air Force, US Navy, US Army, Toshiba. Хотя точные экономические данные получить не представляется возможным в силу их конфиденциального характера, можно утверждать, что использование методов SRE позволяет повысить эффективность программных проектов до шести раз. Установлено, что затраты, связанные с обеспечением надежности, составляют лишь несколько процентов от стоимости проекта. Например, если в проекте участвуют от 40 до 100 исполнителей, то затраты на предпроектную стадию могут составить от одной до двух человеко-недель; определение состава работ (WBS) – от одного до трех человеко-месяцев. Затраты, связанные со сбором и анализом данных о дефектах проекта и усилий, направленных на их устранение, потребуют от половины до одного человеко-дня в неделю. Деятельность по SRE включает в себя: измерение (оценку на основе фактических данных) и прогнозирование (оценку посредством моделей) значений показателей надежности; разработку метрик, характеризующих эффективность использования программных продуктов, а также процессов их реализации. выявление факторов, влияющих на функционирование программных продуктов; 2 использование этих знаний при описании программных продуктов и руководстве их созданием; тестированием; официальной передаче пользователям; использовании и обслуживании. Надежность определяется вероятностью того, что система, либо системная компонента будет обеспечивать требуемые функциональные и нефункциональные характеристики в течение заданного периода времени при заранее заданных характеристиках среды использования в предположении, что система нормально функционировала в начале этого периода. Пример: вероятность того, что система реального времени будет обеспечивать заранее определенную функциональность и производительность в течение десяти часов работы при условии, что она используется для тех целей, для которых предназначена. В силу того, что надежность программного продукта зависит от способа его использования, информация об условиях фактического использования программного продукта является важной составляющей при оценивании надежности. Параметрами среды, в которой происходит фактическое использование продукта, являются: характеристики внешней, по отношению к программному продукту, среды (например, число обращений пользователей к программной системе); частота использования разных функций (свойств системы), предоставляемых программным продуктом. Информация об условиях использования количественно характеризуется посредством «операционного профиля». Время является внешней характеристикой производительности программного продукта, получаемой в результате его применения. Лучшей характеристикой производительности является «собственное время системы» - время выполнения операций центральным процессором (CPU). Вместе с тем, допускается изменение и других параметров для их последующего использования в моделях надежности – например, календарное время; время регистрации по часам; число перезапусков системы; время выполнения и др. В зависимости от тог, «какое время» используется, определяются разные метрики: доступность для вычислений; чувствительность к ошибкам; среднее время наработки до отказа; среднее время восстановления после сбоя и т.д. Использование времени как косвенную объективную характеристику надежности. имеет следующие преимущества. Во-первых, имеет ясно физическое понимание этого показателя. Во-вторых, использование этого показателя дает комплексную характеристику надежности аппаратной и программной компонент. Подчеркнем, что время является лишь одной из возможных косвенных характеристик надежности. Допускается использование и других показателей, например. «число напечатанных страниц» (для принтера). Отказ. Под отказом понимается неспособность системы предоставлять заявленные функции, либо не обеспечивать заявленные нефункциональные характеристики. Отказом является также несоответствие внешних результатов функционирования от требований к программному продукту, либо их несоответствие ожиданиям пользователей. Отказы могут быть обусловлены дефектами в аппаратной, либо в программной компонентах, а также ошибками пользователя. Дефект (fault, defect, bug) – неполные, пропущенные, либо избыточные указания, либо последовательность взаимосвязанных инструкций, следование которым является причиной одной или более свершившихся, либо потенциальных отказов. Разделяют «врожденные» дефекты – те, которые изначально присутствуют в программном продукте. «Дефекты модификации» - те, которые внесены в результате выполнения корректировок. либо изменения проектных решений. В качестве метрической характеристики дефектов выступает плотность дефектов, например количество дефектов на тысячу строк исполняемого кода. Дефекты имеют субъективную природу – они являются следствием ошибок, допущенных людьми. 3 Если, например, допущена ошибка при изображении условного оператора на структурной схеме алгоритма, результатом будет дефект в коде. При выполнении программы будет иметь место ошибка обработки данных (вычисления пойдут не по той ветке), так что пользователь будет наблюдать на экране результат отличный от того, который должен быть. Иными словами, пользователь наблюдает симптом дефекта – отказ программного продукта. Последствия ошибок. Для внешних правообладателей (пользователей, заказчиков программного продукта, спонсоров, кураторов разработки) последствия выражаются в их неудовлетворенности результатами функционирования программного продукта. Для внутренних правообладателей (команды проекта) последствия выражаются дополнительным объемом работ, который связан с поиском и исправлением дефектов. Тяжесть отказов определяется их влиянием на работоспособность систем, в которых программные продукт используется в качестве инструмента поддержки управления. Тяжесть отказов выражается в снижении функциональности (потерях сервисов); экономических показателях (непосредственные потери и упущенная выгода); угрозе безопасности людей; репутационных потерях и др. Многие из этих характеристик не допускают непосредственного измерения (например, репутационные потери), поэтому для их характеристики используются экспертные оценки и балльные характеристики. Операционный профиль. Представляет собою последовательность частот (или вероятностей) выполнения отдельных операций в процессе функционирования программного продукта. Системы, в которых программная компонента является критически важной, могут иметь более одного операционного профиля. Операционные профили служат основой назначения глубины тестирования (чем чаще используются какие-либо операции, тем больше им следует уделять внимания), а также формирования тестовых наборов. Построению операционного профиля предшествует построение «профиля пользователя», «профиля заказчиков», «профиля режимов функционирования», «функционального профиля». Профили конструируются за счет создания детального иерархического списка заказчиков (внешних правообладателей обладающих необходимыми полномочиями при закупках и являющихся лояльными по отношению к программной системе); пользователей (лиц, непосредственно использующих систему); режимов использования программного продукта; функций и операций, которые должны реализовываться в каждом из режимов. Для каждой единицы перечисленных выше профилей необходимо определить вероятность появления и риска отказа. Это создаст возможности для количественного описания профиля. 2. Метрики и модели 2.1. Надежность. Рассмотрим ситуацию, когда фиксация проблемы с последующим выделением дефектов и их устранением осуществляется в ходе создания программного продукта, системного тестирования и опытной эксплуатации, сопровождения в ходе промышленной эксплуатации. В этом случае мы рассчитываем на то, что исправлении, вносимые в программный продукт, способствуют росту надежности. Наиболее употребительной метрикой надежности является частота отказов. Частота отказов определяется как число отказов, зарегистрированных в единицу времени (секунду/час/день/неделю...). Синонимом «частоты отказов» является «относительное число отказов». Другой часто применяемой метрикой является среднее время между отказами. Между интенсивностью отказов и средним временем между отказами существует обратная зависимость. Интенсивность отказов является 4 хорошим показателем качества программного продукта с точки зрения пользователя. При росте надежности во времени, интенсивность отказов падает. Если дефекты не устраняются, можно установить простые соотношения между интенсивностью отказов и надежностью: e t R ) ( , (1) где ) (t R есть характеристика надежности; - определяемый. исходя из назначения системы, период наблюдения. Пример: Допустим, система функционирует в образцовых и неизменных условиях и выявленные дефекты не устраняются. Допустим, что за 10 000 часов зарегистрировано 7 отказов. В этом случае оценка интенсивности отказов составит 4 10 * 7 в час. Средняя наработка между отказами составит 1428 1 T часов. Оценка вероятности безотказной работы в течение ближайших 10 часов составит 993 0 10 * 10 * 7 4 e R В случае, когда имеет место рост надежности, интенсивность отказов становится убывающей функцией (в предположении, что программный продукт тестируется и используется в представительных (образцовых, т.е. определенных в техническом задании на разработку) условиях). Рассмотрим две из множества известных моделей, соответствующих случаю растущей надежности. В обеих моделях предполагается, что устранение отказов происходит мгновенно без внесения новых дефектов. В модели «основное время выполнения» («Basic Execution Time - BET») интенсивность отказов описывается выражением e 0 0 0 ) ( (2) где 0 - начальная интенсивность; 0 - общее ожидаемое число дефектов. Эта модель может быть преобразована к линейному виду ) 1 ( ) ( ) ( 0 0 (3) где ) ( есть среднее число отказов, зарегистрированных в течение времени , т.е. среднее значение функции ) 1 ( ) ( 0 0 0 e (4) В модели LPET (Logarithmic-Poisson Execution Time) интенсивность отказов при периоде наблюдения определяется соотношением 1 ) ( 0 0 Q , (5) где 0 - начальная интенсивность отказов; 5 Q - параметр затухания (насколько уменьшается интенсивность отказов за единицу времени). Выражение (5) можно преобразовать к виду e Q ) ( ) ( , (6) где ) ( есть среднее число отказов. зарегистрированных в течение периода наблюдения , т.е. ) 1 ln( 1 ) ( 0 Q Q , (7) Модель BET относится к классу «моделей с конечным числом отказов». Для этой модели среднее значение функции приближается к некоторому асимптотическому значению по мере роста значения периода наблюдения . Модель LPET относится к классу «моделей с неограниченным числом отказов». В действительности модели, относимые к упомянутым классам, предназначены для поддержки процессов устранения дефектов, которых на самом деле может быть очень ограниченное число. Оценивание параметров упомянутых моделей может выполняться методом наименьших квадратов. Важно отметить, что есть два различных пути использования моделей: 1. Модель как аккумулятор исторических данных. 2. Модель как инструмент прогнозирования состояния, наступления события. Например: «...когда интенсивность отказов достигнет целевой величины...», «...когда я могу закончить тестирование...» Прогнозирование – одно из наиболее интересных приложений модели, но в то же время наиболее опасное. В литературе отмечается, что ни одна из моделей не обеспечивает точного решения задачи прогнозирования. Более того, результаты, полученные посредством разных моделей, могут достаточно сильно различаться. После того, как определена структура модели и рассчитаны значения её параметров, появляется возможность рассчитать общее число дефектов в коде (после выполнения процедур поиска и устранения дефектов); предполагаемую интенсивность отказов; какое время потребуется для того, чтобы довести фактическую интенсивность отказов до целевого значения. Пример: Предположим, что в качестве базовой модели выбрана модель BET. Из формул (2)-(4) следует, что число ошибок, которые следует устранить для того, чтобы достичь требуемой интенсивности отказов, определяется соотношением: ) ( 0 0 F P , (8) где P - фактическая интенсивность отказов. Дополнительное время. необходимое для устранения ошибок, составит F P ln 0 0 (9) 6 В случае, если 120 0 дефектов в коде; 0 =15 отказов в час (например, CPU); при текущем значении P =2.55 отказа в час и при целевом значении F =0.0005 отказов в час, значение ) 0005 0 55 2 ( 15 120 21 отказ. 0005 0 55 2 ln 5 120 68.3 часов (например, CPU). Если известна стоимость одного часа (например,CPU), то можно оценить не только стоимость разработки тестов, необходимых для обеспечения требуемого качества, но и затраты, связанные с прогоном тестов (т.е. речь идет о построении экономической модели качества программного продукта). Приведенные оценки относятся к классу «точечных» и дают значение «вероятных», т.е. средних величин. На практике, однако, важно вычислять также доверительные границы для оценивания параметров и получить меру (т.е. количественную характеристику) того, насколько можно доверять полученным цифрам. Вместо того, чтобы представлять ожидаемые значения в виде одной величины, представляется подходящий интервал (например, 70%, 90%, 95% доверительный интервал). В этом случае, вместо того, чтобы говорить о том, что ожидается 21 отказ, следует говорить о том, что с вероятностью 90% число отказов будет лежать в диапазоне от 17 до 25, т.е. [17,25]. Точность получаемых оценок в значительной степени определяется способом регистрации данных. Например, набор исходных данных может быть представлен значениями моментов времени, когда возникает отказ. Альтернативным вариантом является регистрация величины интервалов между отказами, либо число отказов, наблюдавшихся за период тестирования – группированные данные. Либо в виде описания каждого корректируемого отказа; либо в виде информации о части кода, в которой зафиксирован отказ; либо описанием модулей, на которые оказывают влияние вносимые изменения и т.д. 2.2. Готовность Одной из часто используемых характеристик надежности является готовность. Например, Bell core целевым показателем простоя элементов телекоммуникационной сети определяет 3 минуты в год. Готовность есть вероятность того, что система (элемент системы) окажется работоспособным в заранее указанное время. Неготовность, напротив, означает вероятность того, что система (элемент) окажется неработоспособным в заранее заданный момент времени. Понятие готовности (неготовности) тесно связано с понятием устранения отказов. Количественно устранение отказов можно охарактеризовать коэффициентом восстановления, который определяется числом отказов, устраняемых в единицу времени. Например, отказ в программной компоненте, в среднем приводит к 10-минутному простою аппаратно-программного комплекса. Коэффициент восстановления составит 1/10 на отказ в минуту (по сути коэффициент восстановления представляет собою интенсивность потока восстановления– см. Уравнения Колмогорова). Готовность системы может быть охарактеризована разными показателями. Например, мгновенная готовность выражается вероятностью застать систему исправной в любой момент времени t в течение времени жизни системы. Средняя готовность есть доля заранее определенного временного интервала [0,T], в течение которого система должна быть готовой к использовании. 7 Оценкой средней готовности системы является величина T исправна система которого ттечени в в время суммарное ) ( T A C (10) Соответственно коэффициент простоя (интенсивность отказов) T период за системы состояния обного работоспос время Суммарное T период за (ссобытий) отказов число Общее ) ( T C (11) Коэффициент восстановления (интенсивность восстановления) определен как T период за алась ремонтиров система которого ттечени в время, Общее T период за отказов число Общее ) ( T С Если период T достаточно длинный, средняя готовность преобразуется к виду «установившегося значения средней готовности» SS A . Этому понятию соответствует соотношение (коэффициент простоя) SS A (13) Из этого соотношения следует, что коэффициент простоя (коэффициент неисправности) связан с коэффициентом готовности системы, а также коэффициентом восстановления. Следует обратить внимание на то, что с момента поставки очередной версии программного продукта наблюдается разброс (иногда значительный) в значениях коэффициента простоя. Это так называемая «переходная зона». В дальнейшем значения коэффициента простоя снижается и стабилизируется. На практике значение коэффициента простоя обычно зависит как от профиля использования, так и от способа разрешения проблем. Достаточно нормальной практикой является то, что ) ( ) ( T T C С На практике модели надежности и готовности используются для прогнозирования состояния системы. 3. Практическое использование формального аппарата надежности Практически невозможно обеспечить надежность программного продукта не имея логичного и реалистичного плана верификации процессов и активностей, относящихся ко всем стадиям жизненного цикла. Пример такого плана представлен в IEEE Std – 1012; ESA-PSS – 05-10. SRE предписывает использование современных технологий ориентированных на предупреждение, идентификацию дефектов, обеспечение устойчивости к ним; уменьшение обусловленных ими негативных последствий. SRE предписывает увязывать эти технологии с бизнес-процессами. Это включает в себя конструирование и квантификацию профилей пользователей, а также обеспечение баланса между надежностью программного продукта и другими ограничениями. Практика SRE предписывает сбор и анализ данных о свойствах программного продукта; оценивание и определение направления изменения 8 надежности; управление процессами создания программного продукта в терминах ресурсов, а также критерия «когда остановить тестирование»; отслеживать состояние деятельности, связанной с обеспечением надежности программного продукта. Отслеживание уровня надежности и направления её изменения используется для совершенствования системы управления и поддержки процесса создания прикладного программного продукта и повышения уровня удовлетворенности потребителей. IEEE&ESA-PSS- стандарты V&V (Verification & Validation) предполагают, что на стадии формирования и анализа требований будут решены следующие задачи: анализ взаимосвязи функциональных и нефункциональных требований, соответствующих различным иерархическим уровням представления системы (см. «Дом качества»); классификация требований по значимости (см. «Ранжирование проектов»); анализ взаимовлияния требований (см. «выявление противоречий в требованиях»); планирование генерации системных тестов; планирование генерации тестов приемлемости. SRE аргументирует необходимость этих действий тем, что разработчики, как и пользователи (заказчики) нуждаются в том, чтобы: 1. выявить и классифицировать все дефекты в программном продукте; 2. определить реальные требования к надежности со стороны покупателей и определить с экономической точки зрения компромиссное решение в пространстве трех показателей: сроки – качество - цена; 3. определить профиль пользователей программного продукта; 4. определить целевые показатели надежности программного продукта. Идентификация и классификация отказов программных продуктов, а также тяжести их последствий, зависит от области приложений, а также особенностей сопровождения. Например, U.S. Federal Communications Commissions (FCC) требует, чтобы в случае нарушения сервисного обслуживания более чем на 30 минут, либо в случае, когда нарушение сервисного обслуживания затрагивает интересы более чем 50 000 абонентов, информация об этом в течение не более чем 30-ти минут после наступления события, должна поступать в Federal Communications Commission. В этом контексте, отказ коммуникационной системы может быть классифицирован следующим образом: 1. докладываемый в FCC; 2. простой системы менее 30 минут при отказе в обслуживании менее чем 50 000 абонентам; 3. потеря одного или более обязательных сервисов; 4. потерю функциональности можно компенсировать вспомогательными средствами, либо схожими опциями; 5. незначительные неудобства, либо незначительные потери эффективности. Для того, чтобы понять первопричину отказов, необходимо собрать данные об отказах. Отказы, которые приводят к полному простою системы, в свою очередь могут быть разбиты (в зависимости от фактически выявленных, либо предполагаемых причин) на: отказы аппаратной компоненты; отказы программной компоненты; 9 ошибки персонала; нерасчетные воздействия окружающей среды; неизвестные. Внутри каждого подкласса можно выделить дополнительные категории. Например, если с точки зрения особенностей использования системы важна её готовность (время восстановления), может оказаться полезной классификация отказов по продолжительности устранения. Например, менее 2-х минут; от пяти до десяти минут; от десяти до 30 минут; более чем 30 минут (см. лаб. работу по классификации на основе выборочных данных). Значения целевых показателей надежности устанавливаются исходя из: потребностей пользователей; ограничений используемых технологий разработки прикладного программного обеспечения; возможностей разработчиков; возможностей получения (сбора) данных; организационной модели бизнес-процесса; стоимости разработки (см. лаб. раб. по специальным статистическим методам обработки малых выборок); расписания выполнения работ. Обычно, для того, чтобы достичь определенной категории по показателям надежности, выделяется совокупность частных целей. Например, Bellcome установило общее требование для оценки производительности телекоммуникационных систем. Целевое значение для сетевых переключательных элементов – простой не более 3-х минут в год (при этом время восстановления после отдельного отказа не превышает 30 секунд); фиксируется состояние полного отказа, если сервис недоступен более чем 30 секунд. Это, конечно, не требование надежности, но это требование готовности. Фактически средняя недоступность системы (из-за отказа переключательных элементов) составляет 00000571 0 ) 365 * 24 * 60 ( 3 (мин.) Для вычисления целевого показателя надежности, также необходимо установить целевое значение показателя, связанного с восстановлением системы. Например, приняв упрощающее предположение о том, что система находится в установившемся состоянии, можно воспользоваться соотношением (13) для расчета целевого значения характеристики восстановления. Пусть среднее значение частоты восстановления составляет 3 0 отказа в минуту. В этом случае, зная требуемое значение готовности 1- 0.00000571=0.99999429 и зная частоту восстановлении, посредством (13) можно определить, что средняя частота отказов не должна превышать 0.00000171 отказов в минуту. В стандарте IEEE Std-1012 также предполагается, что следующие задачи решаются в ходе проектирования, кодирования, помодульного и интеграционного тестирования: анализ трассируемости проектных решений и кодов; количественная оценка качества проектных решений, кодов и документации; разработка планов тестирования для программных компонент, а также плана тестирования интеграции; проектирование, генерация и выполнение тестовых наборов. SRE аргументирует необходимость этих действий требованиями того, чтобы разработчики прикладных программных продуктов: определились с функциональностью и сформировали операционный профиль; 10 получили количественные оценки надежности при повторном (многократном, в составе разных программных продуктов) использовании компонентов; четко распределили требования к характеристикам надежности среди программных компонентов и создали продукт, характеристики надежности которого соответствуют целевым значениям показателей; использовали модели распределения ресурсов модели расписаний при выделении объемов работ, в соответствие с функциональными профилями; отслеживали и управляли процессами искусственного внесения дефектов и их устранения (для оценки эффективности систем диагностики). Важным видом деятельности на стадии проектирования является определение целевых показателе надежности для подсистем и компонентов так, чтобы обеспечивалось целевое значение показателя надежности для системы в целом. Назначение целевых показателей надежности для подсистем и компонент носит итерационный характер, и должно основываться на сравнительном альтернативных вариантов реализации программного продукта. Это обусловлено необходимостью обеспечения «баланса» между целевыми значениями показателей надежности системы; стоимостью и временем реализации системы. На всех стадиях создания прикладного программного продукта настоятельно рекомендуется применение инспектирования и критического анализа промежуточных результатов (англ.- inspections and review). Их использование позволяет оценить среднее количество дефектов на конструктивную единицу (оператор/модуль/функцию...). Иными словами, инспектирование и критический анализ (сквозная проверка и контроль) позволяют выявить дефекты на тех стадиях, когда ещё не создана работающая версия программы (для понимания значимости раннего обнаружения дефектов вспомните кривую стоимости устранения ошибки). Практически полезной метрикой является количество дефектов, приходящихся на один человеко-час работы (с учетом классов дефектов). При этом следует учитывать время, затрачиваемое на подготовку и проведение инспектирования. В литературе указывается, что если значение этой метрики лежит в диапазоне от 3 до 7, то как процессы инспектирования, так и процессы разработки программного продукта являются управляемыми. В противном случае, необходимо проанализировать организацию программного проекта и, возможно, внести соответствующие изменения. 11 Задание на работы Лабораторная работа №3 (модель PET) Дано: Модули программной системы соединены последовательно, что определяет интенсивность отказов всего изделия как N i i сист 1 доп) ( . Допустимая интенсивность отказов системы составляет час сист / 1 10 4 Требуется: а) Назначить значение целевой интенсивности для i го модуля ) (i p б) Оценить суммарное время, необходимое для обеспечения приемлемых значений интенсивностей отказов. Исходные данные № варианта Число модулей Начальное число дефектов в i-м модуле ) ( 0 i Начальная интенсивность отказов ) ( 0 i Фактическая интенсивность отказов ) (i F 1 5 120*i 15*i 2.55*i 2 10 75*i 17*i 3*i 3 7 120*i 15*i 2.55*i 4 7 75*i 17*i 3.55*i 5 5 100*i 14*i 2.15*i 6 15 100*i 17*i 5.5*i 7 10 80*i 10*i 2.5*i 8 16 90*i 5*i 4.55*i 9 5 120*i 17*i 1.55*i 10 15 92*i 15*i 3.55*i 11 8 220*i 25*i 4.55*i 12 9 82*i 18*i 3.55*i 13 15 120*i 19*i 7.55*i 14 6 320*i 35*i 8.55*i 15 5 520*i 75*i 6.55*i 16 8 220*i 35*i 2.55*i 17 8 320*i 45*i 6.55*i 18 5 120*i 25*i 0.55*i 19 15 220*i 25*i 3.55*i 20 8 60*i 5*i 0.5*i 21 10 520*i 15*i 8.55*i 22 9 120*i 17*i 4.55*i 23 10 220*i 25*i 3.55*i 24 15 150*i 16*i 0.55*i 25 16 250*i 20*i 0.7*i 12 Лабораторная работа №4 (модель LPET) Дано: а) Целевое значение интенсивности отказов 0 ) ( б) Начальное число интенсивности отказов 150 * 0 k ( k - номер варианта) в) Исходные данные о периодах наблюдения и числе зарегистрированных отказов (см. таблицу). Требуется: а) МНК определить параметр затухания б) Определить время достижения целевого показателя интенсивности отказов Номер варианта Периоды наблюдения Число зарегистрированных отказов 1 1 2 3 4 5 6 100 30 20 25 5 10 2 1 2 3 4 5 6 150 35 23 15 10 12 3 1 2 3 4 5 6 250 45 13 15 10 5 4 1 2 3 4 5 6 250 45 13 65 10 5 5 1 2 3 4 5 6 250 45 13 15 25 5 6 1 2 3 4 5 250 45 20 15 10 13 6 7 7 1 2 3 4 5 6 250 45 13 67 10 5 8 1 2 3 4 5 6 250 98 13 15 10 5 9 1 2 3 4 5 6 400 45 30 15 10 5 10 1 2 3 4 5 6 350 45 13 15 10 5 11 1 2 3 4 5 6 450 45 13 45 10 5 12 1 2 3 4 5 6 550 45 13 78 10 5 13 1 2 3 4 5 6 250 120 13 15 10 5 14 1 2 3 4 5 6 250 98 13 75 10 5 14 15 1 2 3 4 5 6 250 45 13 38 10 5 16 1 2 3 4 5 6 250 45 29 15 10 5 17 1 2 3 4 5 6 250 45 45 15 10 5 18 1 2 3 4 5 6 250 45 67 15 10 5 19 1 2 3 4 5 6 250 45 13 15 10 17 20 1 2 3 4 5 6 250 45 65 15 10 5 21 1 2 3 4 5 6 250 45 13 15 17 5 22 1 2 3 4 5 6 250 45 74 15 10 5 23 1 250 15 2 3 4 5 6 45 7 15 10 5 24 1 2 3 4 5 6 250 45 77 15 10 5 25 1 2 3 4 5 6 250 45 3 15 10 5 Лабораторная работа №5 (характеристики готовности) Дано: Выборочные данные о времени наработки между проявлениями дефектов и времени устранения дефектов (см. таблицу) Требуется: Определить: а) показатель средней готовности системы б) коэффициент простоя в) коэффициент восстановления г) коэффициент простоя Номер варианта № события Время наработки между проявлениями дефектов Время локализации и устранения дефектов 1 1 2 3 4 5 1 2 3 4 5 10 11 9 7 3 2 1 2 3 4 5 11 12 13 14 15 17 11 12 7 3 3 1 2 3 4 5 11 2 13 4 15 7 1 2 7 3 4 1 2 3 4 5 15 12 17 14 15 1 1 2 7 3 16 5 1 2 3 4 5 11 16 17 4 15 10 11 12 7 30 6 1 2 3 4 5 110 12 19 14 15 17 115 12 75 3 7 1 2 3 4 5 11 120 18 14 19 9 11 16 7 15 8 1 2 3 4 5 11 120 110 140 15 170 110 12 80 35 9 1 2 3 4 5 11 120 114 148 153 170 110 120 90 40 10 1 2 3 4 5 21 22 33 44 55 27 11 32 47 53 11 1 2 3 4 5 31 42 53 64 15 37 41 52 17 115 12 1 2 3 4 5 41 52 163 74 155 77 81 92 21 134 13 1 2 3 4 5 51 72 93 24 85 27 31 52 77 93 14 1 2 3 4 71 92 83 114 37 51 72 79 17 5 154 165 15 1 2 3 4 5 21 42 73 114 65 97 110 12 99 108 16 1 2 3 4 5 51 18 93 34 45 170 110 22 9 37 17 1 2 3 4 5 91 120 141 169 158 170 115 126 79 35 18 1 2 3 4 5 117 128 139 145 159 27 41 62 87 93 19 1 2 3 4 5 11 12 13 14 15 17 11 12 7 3 20 1 2 3 4 5 18 129 168 199 189 189 134 116 67 93 21 1 2 3 4 5 114 126 136 147 159 170 1186 128 273 283 22 1 2 3 4 5 161 172 183 124 175 147 511 162 779 382 23 1 2 3 4 5 101 182 164 144 135 117 211 212 37 43 24 1 2 3 111 212 313 117 211 132 18 4 5 144 165 74 355 25 1 2 3 4 5 191 182 143 154 125 187 191 182 755 344 Методика выполнения задания На основе расчетных соотношений определить значения нефункциональных требований в соответствие с темой задания Требования к содержанию и оформления отчета Отчет должен содержать краткие теоретические сведения, обосновывающие необходимость расчета мер нефункциональных требований, исходные данные для расчетов, значения мер нефункциональных требований, ответы на контрольные вопросы. Контрольные вопросы 1. Содержание понятия «нефункциональные требования», отличия функциональных и нефункциональных требований. 2. Как обосновывается выбор номенклатуры нефункциональных требований 3. Как назначаются значения нефункциональных требований на разных стадиях жизненного цикла изделия 4. Как доказывается соответствие фактических значений нефункциональных требований тем, которые определены в спецификациях. Дополнительные вопросы 1. Процессы жизненного цикла программных средств согласно ISO 12207:1995 2. Содержание работ стадий программного проекта согласно РД 50-34.698-90 3. Характеристики качества программного продукта согласно ISO 9126:1991 4. Стадии создания автоматизированных систем согласно ГОСТ 34.601-90 5. Работы стадий создания автоматизированных систем согласно ГОСТ 34.602-89 Критерии оценки выполнения лабораторной работы Задание считается выполненным, если выполнены работы, определенные в разделе «Методика выполнения задания», оформлен отчет, осуществлена его защита. Список литературы 1. Милошевич Д. Набор инструментов для управления проектами – М.: Компания АйТи: ДМК Пресс, 2008. – 729с. 2. ЕSA PSS-05-02 3. ESA PSS-05-03 4. ESA PSS-05-10 5. Гвоздев В.Е., Бежаева О.Я., Блинова Д.В. и др. Практическое руководство по реализации программных проектов-Уфа, УГАТУ,2015 |