Надежность, эргономика и качество АСОИУ

Министерство образования и науки РФ 

Федеральное государственное бюджетное образовательное 

учреждение высшего профессионального образования 

ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ 

УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ 

 

 

 

 

П.В. Сенченко 

 

НАДЕЖНОСТЬ, 
ЭРГОНОМИКА И 

КАЧЕСТВО АСОИУ 

 
 

Учебное пособие 

 

 

 

 

 

 

 

 

 

Томск 2016 

 
 
 

Сенченко П.В. 

Надежность, эргономика и качество АСОИУ: Учебное пособие. – 

Томск: Томск. гос. ун-т систем управления и радиоэлектроники, 2016. 
– 189 с. 
 
 

В учебном пособии рассматриваются вопросы надежности, эргономики и 

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

Учебное пособие ориентировано на студентов направлений подготовки 

бакалавров «Программная инженерия», «Бизнес-информатика» а также студентов родственных специальностей. 
 
 
 
 
 
 
 
 
 
 
 
 

© Сенченко П.В., 2016 
 
 
 

 
 

Содержание 

ВВЕДЕНИЕ ...................................................................................... 6 
1. ПРИНЦИПЫ ОРГАНИЗАЦИИ РАЗРАБОТКИ АСОИУ... 7 

1.1. Краткая характеристика АСОИУ ......................................... 7 
1.2. Стадии разработки системы .................................................. 8 

1.2.1. Обзор стадий разработки системы ................................ 8 
1.2.2. Стадия планирования ...................................................... 9 
1.2.3. Стадия проектирования ................................................ 14 
1.2.4. Стадия кодирования ...................................................... 18 
1.2.5. Стадия  внедрения ......................................................... 19 
1.2.6. Сопровождение системы .............................................. 19 

1.3. Определение состава группы  по созданию 
информационных систем ........................................................... 20 
1.4.  Проблемы  стандартизации  нормативов  разработки 
информационных систем ........................................................... 24 

2. СТАНДАРТЫ КАЧЕСТВА АСОИУ .................................... 29 

2.1. Общая характеристика стандартов качества АСОИУ ...... 29 
2.2. Стандартизированные показатели качества  
информационных систем ........................................................... 34 
2.3. Показатели качества баз данных ........................................ 48 
2.4. Выбор характеристик и метрик качества АСОИУ ........... 52 
2.5. Сравнение качества АСОИУ по критерию  
функциональной полноты .......................................................... 59 

3. НАДЕЖНОСТЬ АСОИУ ........................................................ 71 

3.1. Основные положения теории надежности ........................ 71 
3.2. Основные показатели надежности АСОИУ ...................... 73 
3.3. Методы повышения надежности АСОИУ ......................... 81 

3.3.1. Минимизация влияния дестабилизирующих факторов
 ................................................................................................... 81 
3.3.2. Оптимизация процесса проектирования систем ........ 83 
3.3.3. Проверка достоверности надежности АСОИУ .......... 92 

4. ЭРГОНОМИКА АСОИУ ........................................................ 96 

4.1. Общие сведения ................................................................... 96 
4.2. Оптимальные задачи эргономики ...................................... 99 
4.3. Основные эргономические проблемы АСОИУ .............. 102 
4.4. Эргономика пользовательского интерфейса АСОИУ .... 103 

4.4.1. Основные принципы проектирования ....................... 103 

4.4.2. Размещение информации на экране .......................... 106 
4.4.3. Выделение элементов интерфейса ............................. 107 
4.4.4. Непротиворечивость и стандартизация .................... 109 
4.4.5. Меню и пиктограммы (иконки) ................................. 110 
4.4.6. Формы .......................................................................... 112 
4.4.7. Тексты и диалоги ......................................................... 113 
4.4.8. Элементы управления ................................................. 114 
4.4.9. Дизайн заголовков и полей......................................... 115 
4.4.10. Форматы ввода .......................................................... 115 
4.4.11. Организация системы навигации и системы 
отображения состояний ........................................................ 116 
4.4.12. Проектирование сообщений ..................................... 116 
4.4.13. Таблицы ...................................................................... 118 

4.5. Эргономическая экспертиза .............................................. 119 

5. ДОКУМЕНТИРОВАНИЕ АСОИУ ..................................... 120 

5.1. Общие сведения о документации АСОИУ ...................... 120 
5.2. Проектная и общесистемная документация .................... 122 

5.2.1. Технические предложения ......................................... 122 
5.2.2. Техническое задание ................................................... 122 
5.2.3. Исходная спецификация на систему ......................... 124 
5.2.4. Проектная оценка надежности системы ................... 126 
5.2.5. Программа и методика испытаний АСОИУ ............. 127 

5.3. Пользовательская документация ...................................... 130 

5.3.1. Состав пользовательской документации .................. 130 
5.3.2. Общее описание системы ........................................... 130 
5.3.3. Руководство по управлению системой ...................... 131 
5.3.4. Руководство пользователя .......................................... 131 

5.4. Внутренняя документация системы ................................. 132 

5.4.1. Спецификация тестирования системы ...................... 132 
5.4.2. Отчет о тестировании системы .................................. 132 
5.4.3. Руководство программиста ........................................ 133 
5.4.4. Описание структуры и глоссарий базы данных ....... 134 

5.5. Дополнительная документация ........................................ 135 
5.6. Стандартизация  качества  служебной  информации ..... 135 

6. ТЕСТИРОВАНИЕ АСОИУ .................................................. 140 

6.1. Верификация и валидация системы ................................. 140 
6.2. Тестирование на стадии кодирования .............................. 143 

6.3. Регрессионное тестирование............................................. 145 
6.4. Тестирование «черного ящика» ........................................ 146 

6.4.1. Полный цикл тестирования разработанного 
программного продукта ........................................................ 146 
6.4.2. Стандартная процедура тестирования  «черного 
ящика» .................................................................................... 147 
6.4.3. Тестирование производительности ........................... 149 

6.5. Завершающие этапы тестирования .................................. 150 
6.6. Тестирование на этапе сопровождения ........................... 154 
6.7. Организация и проведение испытаний  на надежность . 156 

6.7.1. Цели и задачи проведения испытаний ...................... 156 
6.7.2. Технологическая схема испытания ........................... 158 
6.7.3. Планирование и оценка завершенности испытаний 160 
6.7.4. Автоматизация проведения испытаний  и процесса 
тестирования .......................................................................... 161 

6.8. Анализ и интерпретация результатов тестирования ...... 163 
6.9. Программные ошибки ....................................................... 164 

Литература ................................................................................... 171 
Приложение ................................................................................. 173 

 
 
 

Никогда не выявляйте в программе 
ошибки, если не знаете, что с ними 
делать дальше. 

Руководство по системному  
программированию Штейнбаха 

ВВЕДЕНИЕ 

 
В настоящее время при разработке автоматизированных 

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

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

Изучение материала, представленного в пособии, предпола
гает знание студентами таких дисциплин, как «Метрология, 
стандартизация и сертификация», «Информационные технологии», «Интерфейсы АСОИУ». 

 
 
 

1. 
ПРИНЦИПЫ 
ОРГАНИЗАЦИИ 
РАЗРАБОТКИ 

АСОИУ1 

1.1. Краткая характеристика АСОИУ 

АСОИУ описывается как система, представляющая собой 

совокупность средств сбора, хранения и отображения информации, аппаратных, математических и телекоммуникационных 
средств. В большинстве своем АСОИУ относятся к классу систем 
«человек-компьютер» (человеко-машинные системы). АСОИУ 
находят применение во всех областях жизнедеятельности человека, к ним можно отнести и системы учета населения, и бухгалтерские комплексы программ и даже системы управления 
атомными электростанциями. Независимо от области применения основными функциями систем являются обработка некоторой информации и управление различными процессами.  

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

Проектирование АСОИУ подразумевает разработку раз
личных уровней моделей системы. Для функционального, ин
 

1 Данная глава написана по материалам, представленным в [1, 2]. 
 

формационного и имитационного моделировании будущих 
АСОИУ возможно использование различных методологий. 
Например, функциональная модель системы может быть реализована виде SADT-диаграмм (Structured Analysis and Design 
Technique — технология структурного анализа и моделирования). Техническими средствами реализации функциональных  
моделей являются пакеты BPwin, IDEF/Design, Visio Professional 
и др. (обзор средств проектирования и моделирования систем 
представлен в п. 1.3.2).  

1.2. Стадии разработки системы 

1.2.1. Обзор стадий разработки системы 

Процесс разработки АСОИУ состоит из следующих стадий 

(этапов): 

1) планирование; 
2) проектирование; 
3) кодирование; 
4) тестирование; 
5) документирование; 
6) внедрение; 
7) сопровождение. 
Обычно этапы жизненного цикла создания АИС описывают 

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

На этапе разработки технических требований стоимость 

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

Исправление программистом ошибок, обнаруженных в ходе 

написания системы, не влечет больших затрат. Ему не нужно 

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

В случае внесения исправлений в разрабатываемую версию 

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

Следует учесть, что чем позднее обнаруживается ошибка, 

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

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

На стадии документирования разрабатывается техническая 

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

1.2.2. Стадия планирования 

Стадия планирования включает следующие этапы: 
 определение целей; 

 анализ требований; 
 определение функциональных характеристик продукта; 
 тестирование на этапе планирования. 

Определение целей 
Планирование начинается с формирования общего видения 

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

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

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

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

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

Определение функциональных характеристик  
программного продукта 
Этап определения функциональных характеристик можно 

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

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

Оба подхода имеют как недостатки, так и достоинства. 

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

Тестирование на этапе планирования 
На этом этапе тестируются не программы — «тестируются» 

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

Суть тестирования на этом этапе заключается в следующем. 

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

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

Адекватны ли эти требования? Действительно ли именно 

такую информационную систему хочет создать компания? 

Полны ли вырабатываемые требования? Не упущены ли 

какие-либо полезные или даже жизненно необходимые функции? 
Нельзя ли ослабить какие-либо из перечисленных требований? 

Совместимы ли требования между собой? Требования к 

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

Выполнимы ли требования? Не требуется ли для нормальной 

эксплуатации продукта более мощное, чем указано в документации, аппаратное обеспечение (больший объем памяти, более 
высокая пропускная способность, большее разрешение и т. д.)? 

Разумны ли вырабатываемые требования к создаваемому 

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

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

Поддаются ли вырабатываемые требования тестирова
нию? Насколько легко можно будет определить, соответствует ли 
инженерно-проектная документация требованиям к программному продукту. 

На практике возникают ситуации, когда специалисты на 

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

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

Такая дискуссия может осветить самые различные аспекты 

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