Разработка информационных средств оценки качества интерфейса программного продукта на основе UX-метрик

Стадникова А.А.

Разработка информационных средств оценки качества интерфейса программного продукта на основе UX-метрик

38.04.05 Бизнес-информатика

Информатика

Дипломы

Вуз: Белгородский государственный университет - национальный исследовательский университет (НИУ «БелГУ»)

ID: 5c1a76877966e104f6f85afa

UUID: ef1d0390-e5db-0136-0542-525400005860

Язык: Русский

Опубликовано: почти 6 лет назад

Просмотры: 103

Стадникова А.А.

Источник: Федеральное государственное автономное образовательное учреждение высшего образования «Белгородский государственный национальный исследовательский университет»

Комментировать 0

Рецензировать 0

Скачать - 1,7 МБ

Поделиться работой

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «БЕЛГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ» (НИУ «БелГУ») ИНСТИТУТ ИНЖЕНЕРНЫХ ТЕХНОЛОГИЙ И ЕСТЕСТВЕННЫХ НАУК КАФЕДРА ПРИКЛАДНОЙ ИНФОРМАТИКИ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ РАЗРАБОТКА ИНФОРМАЦИОННЫХ СРЕДСТВ ОЦЕНКИ КАЧЕСТВА ИНТЕРФЕЙСА ПРОГРАММНОГО ПРОДУКТА НА ОСНОВЕ UXМЕТРИК Выпускная квалификационная работа обучающегося по направлению подготовки 38.04.05 «Бизнес-информатика» заочной формы обучения, группы 07001574 Стадниковой Алины Анатольевны Научный руководитель д.т.н., профессор Черноморец А.А Рецензент к.т.н., доцент кафедры информационных систем НИУ «БелГУ» Жихарев А.Г. БЕЛГОРОД 2018 1

СОДЕРЖАНИЕ ВВЕДЕНИЕ...................................................................................................... 3 1 Исследование методик и технологий проектирования взаимодействия пользователя и программного продукта....................................... 6 1.1 Анализ существующих UX-метрик..................................................... 6 1.2 Анализ оценки качества взаимодействия работы программного продукта и пользователя как фактор повышения эффективности продукта ...... 11 1.3 Подходы к проектированию опыта взаимодействия и анализ методов показателей качества информационной системы .................................................. 19 1.4 Проблемные стороны современных методик и технологий оценки качества интерфейса программного продукта ....................................................... 24 1.5 Оценка подходов к диагностике состояния программного продукта 27 2 Анализ предметной области и технологий построения систем ............ 31 2.1 Сравнительная оценка качества информационной системы .............. 31 2.2 Построение исходной концептуальной модели предметной области 37 2.3 Разработка структуры базы данных и интерфейса информационной системы страховой деятельности ............................................................................ 45 2.4 Моделирование бизнес-процессов информационной системы страховой деятельности ............................................................................................ 54 3 Разработка методики оценки качества взаимодействия работы программного продукта и пользователя с использованием UX-метрик ............. 59 3.1 продукта Систематизация критериев оценки функций программного 59 3.2 Разработка требований к техническому обеспечению ....................... 61 3.3 Разработка модели оценки качества программного продукта ........... 62 ЗАКЛЮЧЕНИЕ ............................................................................................. 75 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ................................... 77 ПРИЛОЖЕНИЯ............................................................................................. 83 2

ВВЕДЕНИЕ На сегодняшний день невозможно представить любой бизнес без использования информационных систем. Они являются неотъемлемой частью успешности ведения бизнеса. Каждая компания стремится улучшить свое управление, повысить эффективность своей деятельности, а также быть лидирующей в своей отрасли среди конкурентов. Одной из самых главных мер успешности программного продукта является измерение того, сколько пользователей им пользуются. Поэтому уже на начальном этапе разработки необходимо провести оценку качества информационной системы. Данную возможность предоставляют UXметрики. Актуальность выпускной квалификационной работы заключается в том, что высокое качество программного продукта в современном состоянии рынка является необходимым условием роста эффективности бизнеса, создания, развития и реализации конкурентных преимуществ между компаниями. Оценка качества программного продукта с использованием UX-метрик имеет сегодня обширные перспективы. Применение высокого качества информационных систем имеет большие успехи для компании и в целом для бизнеса. Объектом исследования является организационное обеспечение и требования к качеству интерфейса программного продукта. Предметом исследования являются UX-метрики и модели оценки качества взаимодействия работы программного продукта с пользователем. Целью выпускной квалификационной работы является повышение качества интерфейса программного продукта за счет созданной модели оценки информационной системы на основе UX-метрик. Реализация поставленной цели обусловлена необходимостью решения следующих задач: 3

1) Исследовать методики и технологии проектирования взаимодействия пользователя и программного продукта. 2) Проанализировать предметную область и технологию построения системы. 3) Разработать методику оценки качества взаимодействия работы программного продукта и пользователя с использованием UX-метрик. Научную новизну работы составляют: - использование системы поддержки принятия решений для сравнения аналогов информационных систем страховой деятельности с предварительно установленными критериями; - комплекс критериев оценки функций программного продукта, позволяющие определить коэффициент качества информационной системы; - разработанная модель оценки качества программного продукта, с применением UX-метрик, позволяющая при оценивании системы понять полноту определения целей и требований к информационной системе. Практическая значимость работы заключается в использовании разработанной модели оценки качества интерфейса программного продукта на основе UX-метрик и обеспечении повышения эффективности управления, качества, надежности и удобства использования системы. Методами исследования, применяемыми в выпускной квалификационной работе, являются:  метод анализа документации;  метод сравнения;  метод моделирования;  моделирования бизнеса в нотации ARIS. В рамках исследованы первого методики и этапа выпускной технологии квалификационной проектирования работы взаимодействия пользователя и программного продукта: проанализированы существующие UXметрики и методы показателей качества информационной системы, изучены оценки качества взаимодействия работы 4 программного продукта и

пользователя, рассмотрены подходы проектирования взаимодействия и подходы диагностики состояния программного продукта. В рамках второго этапа выпускной квалификационной работы в качестве примера программного продукта была рассмотрена информационная система страховой деятельности, проведена сравнительная оценка качества системы, посредством сравнения существующих на рынке ИКТ информационных систем. Построена концептуальная модель предметной области. Установлены требования к информационной системе. Созданы основные модели бизнес-процессов и их декомпозиции, проведена разработка структуры базы данных и интерфейса информационной системы. Разработана блок-схема алгоритма работы системы. В рамках третьего этапа была разработана методика оценки качества взаимодействия работы информационной системы и пользователя. Для определения качества функционирования были систематизированы критерии оценки функций взаимодействия работы системы и пользователя, которые применяются в области оценки характеристик качества системы. Определено предназначение рассматриваемой разрабатываемому совместимость с системы, программному приложениями основные обеспечению, операционной требования к информационная системы. Также была спроектирована модель оценки качества программного продукта, с изначально установленными требованиями к информационной системе. Определены шаги оценки качества информационной системы страховой деятельности, где были выделены: характеристики, промежуточные характеристики, детальные характеристики, подготовлены процедуры и средне взвешены. Выпускная квалификационная работа состоит из введения, трех разделов, заключения, списка использованных источников из 61 наименования. Основная часть работы изложена на 75 страницах машинописного текста, содержит 18 рисунков и 21 таблицу. В состав работы входит 5 приложений, не вошедших в основную часть. 5

1 Исследование методик и технологий проектирования взаимодействия пользователя и программного продукта 1.1 Анализ существующих UX-метрик Как известно, развитие аппаратных компьютерных средств являлось важной задачей в первые три десятилетия компьютерной эры. Это обусловлено тем, что была высокая стоимость обработки и хранения данных.1 На сегодняшний момент замечается наиболее повышенное внимание к процессам перехода в шестой технологический уклад как в плане развития и усложнения самой технической сферы, так и интенсификации информационных процессов, которые сопровождают это явление. Наиболее главное место среди них занимают когнитивные технологии, не только с целью создания взаимодействия человека и машины, но и как следствие усилить его интеллектуальную и интуитивную сферу. Процессы генерирования новейших знаний являются доминирующими в разных сферах деятельности человека, а уметь конвертировать их в изобретения, какие-либо открытия, современные технологии и программные интеллектуальную продукты, собственность информационные является важным системы, в квалификационным требованием к специалистам. Наиболее главную остроту, на сегодняшний момент, в условиях конкуренции и в процессе быстрого перехода общества в информационную сферу развития приобретает проблема новизны технических решений в среде появления современных информационных продуктов и технологий.2 Для стадий концептуальных систем является характерным наиболее низкая структурированность предметной области, сложность протекающих процессов, нехватка необходимой информации о продвижении динамики, а также изменчивость процессов во времени, что является следствием неопределенности в принятии 1 решений. Формулирование Функционально-ориентированные метрики [Электронный ресурс] / Н. Сапожников – Режим доступа: http://megapredmet.ru/1-35770.html, свободный. 2 ГОСТ Р ИСО/МЭК 15910–2002.Информационная технология. Процесс создания документации пользователя программного средства. 6

требований для постановки задач на проектирование новой, современной, технической информационной системы программного продукта является результатом данной стадии концептуальной разработки.1 Данные технологии позволяют сформулировать определенные требования к структуре системы со стороны функциональности, а также определить ее принцип действия. Общая методика проекта информационной системы на примере концептуального проектирования автоматизированной информационной системы (далее – АИС) включает в себя следующую последовательность: 1) Необходимо собрать всю информацию о предметной области и сформулировать цель проектирования. 2) Смоделировать объекты и процессы проектированной информационной системы. 3) системы Провести анализ существующих уже аналогов и прототипов для того, чтобы определить основные функциональные характеристики и выявить обобщенную функциональную структуру будущего проекта. Это необходимо для того, чтобы сформировать общий массив функциональных требований для новой проектируемой системы. Чтобы выявить существующие недостатки, которые можно разделить на три направления, такие как:  недостатки со стороны функциональной структуры информационной системы;  недостатки отдельных функций системы прототипа;  конструктивные недостатки функциональных элементов системы. 4) Сформулировать ряд задач на проектирование новой системы. Это производится согласно проведенному анализу и выводам по обзору аналогов и прототипов и составляется перечень требований к новой проектируемой системе. 1 Расс Уингер, Кэролайн Чендлер. UX-дизайн. Практическое руководство по проектированию опыта взаимодействия. Символ-Плюс, 2011. 7

5) Разработать концептуальную схему информационной системы. Данная схема представляет собой общие информационные и функциональные компоненты проектируемой информационной системы программного продукта, а также позволяет понять принцип взаимодействия пользователя с информационной системой программного продукта.1 В последнее время, уже около два десятилетия, активно развивается новая отрасль эргономики, которая имеет еще название как юзабилити, где задача которой является создать наиболее удобные компьютерные интерфейсы. Данное направление имеет наиболее актуальную проблему – это разработка методов психологического анализа деятельности пользователей. 2 Количественными показателями юзабилити являются метрики. Для разнообразных проектов актуальными является разные метрики. Наиболее используемыми являются показатели, такие как:  успешность выполнения заданий. То есть возможное использование бинарного кода: например, справился или не справился с заданием. Но в основном придерживается подход Нильсена и выделяется три вида оценок успешности, это: а) выполнение заданий практически без проблем — 100%; б) выполнение заданий самостоятельно, но были некие проблемы — 50%; в) невыполнение с заданием — 0%.  время выполнения заданий. Данная метрика показательна только в сравнении;  частотность проблем. В виде отчета представляет собой список проблем о юзабилити-тестировании, с которыми столкнулись респонденты. Метрика применима, если пользователи ИС выполнили определенный набор 1 ГОСТ Р ИСО/МЭК12207–99. Информационная технология. Процессы жизненного цикла программных средств. 2 Милютин А., «Метрики кода программного обеспечения» [Электронный ресурс] - Режим доступа: http://www.viva64.com/ru/a/0045/, свободный. 8

одинаковых заданий. Если задания выполнены были неверно, то подсчет частности будет непростым;  субъективная субъективную оценку удовлетворенность. пользователем Представляет удобства/комфорта собой работы с информационной системой. Она нацелена на выявление разных опросников, где в процессе или после тестирования заполняют пользователи. Эти метрики являются далеко не единственными. Также существует список, который представляет 10 UX-метрик, выведенные Джефом Сауром, такими метриками являются: 1) Скорость завершения: показатели завершения являются простой мерой удобства использования. Как правило он записывается как двоичный показатель (1 = Успех задачи и 0 = Неисправность задачи). Если пользователи не могут выполнить свои цели, то это не имеет большого значения. 2) Проблемы с юзабилити – проблемы с интерфейсом, с или без оценки серьезности. Данная метрика заключается в том, что нужно проблему описать и обратить внимание на то, сколько и какие пользователи столкнулись с ней. Необходимо понять вероятность, когда и на каком этапе пользователь может столкнуться с проблемой. Это может послужить важным показателем для измерения воздействия активности юзабилити. В случае, если знать какой из пользователей с этим столкнулся, можно наиболее точно прогнозировать размер выборки, скорость обнаружения проблем и с какими проблемами сталкивается один и тот же пользователь. 3) Время задачи: фактической продолжительностью является общая продолжительность задач. Для этого нужно записывать сколько потребуется пользователю времени в секундах и / или минутах на выполнение задачи. Запуск задачи, необходимо только тогда, когда пользователи заканчивают чтение сценариев задач и заканчивают время, когда пользователи завершили все действия, включая проверку. 4) Удовлетворение заданного уровня: после завершения определенной задачи пользователю необходимо ответить на вопрос или ряд вопросов о том, 9

насколько сложное было выполнение задачи. Исходя из ответа собираются показатели, из которых можно обозначить наиболее сложную задачу из базы других задач, которые выполнял пользователь. 5) Удовлетворение тестового уровня: после окончания тестирования ИС пользователям предлагают ряд вопросов об общих впечатления и простоты использования системы. 6) Ошибки: нужно записать любые непреднамеренные действия, упущения, ошибки или возможно промахи, которые участник делает при попытке выполнения задачи. А также записать каждый экземпляр ошибки вместе с описанием. Например, «пользователь ввел имя в поле фамилии». Впоследствии можно также добавить оценки критичности к ошибкам или классифицировать их по определенным категориям. Ошибки помогают проанализировать проблемы информационной системы, а также на основе анализа ошибок помогают обеспечить отличную диагностическую информацию. Для сбора анализа ошибок требуется достаточно много времени. Обычно этим занимаются модераторы или кто-то, кто мог бы просматривать записи, но можно и автоматизировать данный сбор, например, в Webnographer. 7) Ожидание: у пользователей есть ожидание о том, как сложная задача должна основываться на тонких репликах в сценарии задач. Задавать пользователям, насколько сложно ожидать от них задачи и сравнивать ее с реальными задачами (от тех же или разных пользователей), это может стать полезным при диагностировании проблемных областей. 8) Просмотры страниц / кликов. Для веб-сайтов и веб-приложений эти основные показатели отслеживания могут быть единственным, к чему есть доступ, без проведения собственных исследований. Было показано, что клики сильно коррелируют с временем выполнения. Об успехе или неудачи может быть показателен уже первый щелчок. 9) Конверсия. Измерением меры эффективности является то, могут ли участники регистрироваться в информационной системе или покупать продукт. Коэффициенты конверсии представляют особый тип коэффициента завершения 10

и являются существенной метрикой в электронной коммерции. Коэффициенты конверсии также являются двоичными (1 = конвертировано, 0 = не конвертировано) а также могут быть зафиксированы на всех этапах процесса продажи с целевой страницы, регистрации, проверки и покупки. Часто это сочетание проблем использования ошибок и времени, которые приводят к снижению коэффициента конверсии. 10) Единая метрика юзабилити (SUM): бывают случаи, когда проще описать удобство использования системы или задачи, объединяя метрики в единый балл, например, при сравнении конкурирующих продуктов или отчетов на корпоративных панелях. СУМ является стандартизированным средним показателями эффективности, эффективности удовлетворения и в основном состоит из 3 показателей: коэффициентов завершения, удовлетворения на уровне задач и времени выполнения задачи.1 При использовании метрик классическим юзабилити-тестированием является качественное тестирование. Полученные метрики в первую очередь иллюстративны. Они дают общий взгляд на различные сценарии в продукте и позволяют увидеть болевые точки. К примеру, что настроить аккаунт вызывает больше сложностей, чем зарегистрироваться в системе. При регулярном измерении они позволяют увидеть динамику изменений. То есть метрики могут позволить понять, что в новом дизайне выполнение задачи стало быстрее. Именно эти отношения гораздо более надежны и показательны, чем найденные абсолютные значения метрик. 1.2 Анализ оценки качества взаимодействия работы программного продукта и пользователя как фактор повышения эффективности продукта 1 Расс Уингер, Кэролайн Чендлер. UX-дизайн. Практическое руководство по проектированию опыта взаимодействия. Символ-Плюс, 2011. 11

Исходя из поставленных в выпускной квалификационной работе задач, немало важным является проанализировать работу взаимодействия пользователя и интерфейса информационных систем. На сегодняшний день для того, чтобы компания имела наибольший показатель конкурентоспособности, а также возможность ее повышения, необходимым условием является использование информационных технологий. К основным видами IT-проектов относятся:  инфраструктурные и организационные проекты;  проекты разработки и развития программного обеспечения;  проекты внедрения информационных систем. 1 Для сохранения достойного места на рынке компаниям необходимо автоматизировать свою деятельность, для того чтобы реализовать новые стратегические планы, а не решать обыденные вопросы. Сегодня компании стараются внедрять новые, современные ИС и это рассматривается как простой проект, который не отличается, например, от строительства объектов, закупка оборудования и т.д. Внедряя ИС, главным является не только оценка будущих затрат, но необходим и анализ положительных эффектов от внедрения. Результаты, которые объявлены стратегическими, в процессе оценки не сравниваются между собой и не оказывают влияние на показатели бизнеса в общем. К критериям оценки качества программных продуктов относятся:  качество программного средства;  свойство программного средства;  критерий оценки качества программного средства;  функциональность программного средства;  правильность (корректность ПС);  способность к взаимодействию;  защищенность; 1 Бородакий, Ю.В. Информационные технологии. Методы, процессы, системы / Ю.В. Бородакий, Ю.Г. Лободинский. - М.: ГЛТ , 2004. - 456 c. 12

 надежность программного средства;  эффективность программного средства;  практичность программного продукта;  сопровождаемость программного продукта;  мобильность программного средства. Наглядное представление основных критериев качества программных продуктов представлено на рисунке 1.1. Рисунок 1.1 - Основные критерии оценки качества программных продуктов В хорошем стиле должен разработан и пользовательский интерфейс, который должен придерживаться определенных рекомендаций, например, таких как: 13

 интерфейс должен основываться на терминах и понятиях, которые знакомы пользователю;  должен быть единообразным;  иметь возможность пользователю исправлять собственные ошибки и др.1 Существуют стандарты определения качества ПО, например, в таких стандартах, как ISO/IEC 91261:2001 и ISO/IEC 25010:2011. Различают понятия внутреннего качества, которое связанно с характеристиками программного обеспечения самого по себе, без учета его поведения и внешнего качества. Существуют метрики для всех этих аспектов качества, позволяющие оценить их. Кроме того, для создания качественного программного обеспечения существенно качество технологических процессов его разработки. Взаимоотношения между этими аспектами качества по схеме, принятой ISO/IEC 9126 (ISO/IEC 9126-1:2001; ISO/IEC TR 9126-2:2003, ISO/IEC TR 91263:2003, ISO/IEC TR 9126-4:2004), показано на рисунке 1.2. 2 Рисунок 1.2 - Основные аспекты качества ПО по стандартам ISO/IES 9126-1:2001 и ISO/IES 25010:2011 В случае, если положительные результаты использования или создания программного продукта перевешивают негативные мнения, то качество ПО считается «достаточно хорошими». Такой подход проверяет различные 1 ГОСТ Р ИСО/МЭК14764–2002.Информационная технология. Сопровождение программных средств. Обзор стандарта ISO 9126 [Электронный ресурс] / ISO 9126 (ГОСТ Р ИСО / МЭК 9126-93) – "Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению - Режим доступа: http://mediaknowledge.ru/fcc29aa7ecb359ec.html, свободный. 2 14

варианты реализации с точки зрения традиционного понятия качества ПО. В случае такого подхода к качеству ПО значительные и непроверенные требования заменяются наиболее оптимальными. Этот подход сфокусирован на идентифицирующих задачах и с целью улучшения возможностей для принятия решений. Качество ПО, согласно понятию «достаточно хорошее» является оптимальным для решения поставленного ряда задач. Данный способ должен согласовывать анализируемые задачи, а также сформировать альтернативные варианты, сравнивая их с соответствующими процессами жизненного цикла (ISO/IEC 12207:2008). Таблица 1.1 - Порядок оценки качества программного обеспечения. Заинтересованные стороны Разработчик Испытательные и сертификационные центры Пользователь Разраб отка Да Испыт ания Да - Да - - Этапы жизненного цикла ПО Тиражиров Внедре Сопровожд ание ние ение Да Да Да Эксплуат ация Да - Да - Да - - - Да Качество представляет собой набор характеристик объекта, которые имеют отношение к способности соответствовать установленным потребностям. Стандарт ISO/IEC 9126 подразумевает, что все возможности ПО предназначены для удовлетворения пользователей в определенном контексте использования. Существуют атрибуты и факторы внутреннего и внешнего качества ПО в соответствии с ISO/IEC 9126. 1 Так как сфера применения концепции является оценкой качества программного кода, то в этом случае используются непосредственно только те метрики, которые относятся к исходному коду, а также некоторые из шести характеристик согласно ISO/IEC-9126, которые не пригодны для оценки 1 ГОСТ Р ИСО/МЭК12207–99. Информационная технология. Процессы жизненного цикла программных средств. 15

качества.1 Внутреннее качество программного кода оценивается только на основе четырех характеристик: функциональность, эффективность, сопровождаемость и мобильность. У каждой характеристики есть еще набор подхарактеристик. Эти характеристики представлены на рисунке 1.3. Предоставленный комплекс качественных характеристик является довольно общим, чтобы удовлетворить основную цель работы, заключающаяся в создании концепции, поддерживающая систему оценки качества программного кода. 2 Рисунок 1.3 – Внешние характеристики и подхарактеристики согласно серии стандартов, ISO/IEC 9126. Обоснование эффективности ИС заключается в том, что при вложениях инвестиций можно использовать главные принципы оценки эффективности инвестиционных проектов, учитывая особенности проектирования в области информационных технологий. Опыт взаимодействия представляет часть клиентского опыта, который включает отдельные аспекты «вне продукта», которых нет в UX. Опыт взаимодействия (UX) представляет собой опыт конечного пользователя в ИС. 1 ГОСТ Р ИСО/МЭК 15910–2002.Информационная технология. Процесс создания документации пользователя программного средства. 2 ГОСТ Р ИСО/МЭК12119–2000.Информационная технология. Пакеты программ. Требования к качеству и тестирование. 16

UX включает в себя взаимодействие пользователя с ИС и опыт, который он получает в ходе этого взаимодействия. Для того, чтобы сделать цифровой продукт и его интерфейс наиболее простым, удобным и приятным в использовании UX предназначено для исследования, проектирования и тестирования программного продукта. Таким образом, UX можно измерить следующими метриками:  уровень результативности;  время на выполнение задачи;  коэффициент ошибок;  показатель отказов;  легкость выполнения задачи;  уровень вовлеченности;  простота поиска по странице. С помощью UX-исследования можно понять, как услуга или программный продукт будут работать после реализации, а также заранее понять потребности пользователя, что поможет заложить основу дизайна программного продукта. Исследование модели на 5 этапах предложила Эрин Сандерс, где имеет название «Спираль погружения в исследование». На первых двух этапах формируются вопросы и гипотезы, а на следующих собирается информация при помощи конкретных методов: 1) Цели. Чего мы не знаем о пользователях? 2) Гипотезы. Что мы ‒ вроде бы ‒ знаем? 3) Методы. Какие методы мы будем использовать с учетом времени и ресурсов, которыми располагаем? 4) Сбор данных. Собираем информацию с помощью выбранных методов. 17

5) Синтез. Заполняем пробелы в знаниях, подтверждаем или опровергаем наши гипотезы и открываем возможности для работы над дизайном. UX-исследование является исходной точкой для каждого проекта. С помощью данного исследования можно понять поведение, цели проекта. И проанализировать, как пользователь ориентируется на сайте, какие возникают проблемы в ходе работы, а также ощущения от взаимодействия с продуктом. Прежде чем начать создавать дизайн продукта нужно начать с UXисследования, чтобы не закладывалась база только на субъективных предположениях и личном опыте. Ценность данного исследования заключается в том, что оно позволяет снизить неопределенность в понимании того, чего хотят и в чем нуждаются пользователи. От этого выигрывают и сам продукт, и бизнес, и пользователи. С помощью UX-исследования получают данные о конечном пользователе, как и когда будет использоваться продукт и какие в последующем проблемы может решить продукт. На сегодняшнее время UX-исследования являются важными для ведения успешного бизнеса. Оно позволяет ускорить разработку продукта, сократить издержки на редизайн и повысить уровень удовлетворенности пользователей на начальном этапе. Главной чертой UX-исследования является, то что оно имеет прямое обращение к мнению пользователей ИС, то есть как бы озвучивает мысли пользователей без влияния внешних приоритетов и служит главным звеном между пользователем и производителем. Эффективность применения описанных выше метрик будет применена на примере исследования информационной системы страхования. Таким образом, можно сделать вывод, что цель UX-исследования заключается в обнаружении образцов поведения, предпочтения пользователей продукта. Эти понятия и обеспечивают основу для дизайна программного 18

продукта. Исследования помогают бороться с практикой проектирования для заинтересованных сотрудников компании. 1.3 Подходы к проектированию опыта взаимодействия и анализ методов показателей качества информационной системы Процессы, которые связанны с разработкой, приобретением и внедрением ИС, к которым относятся программные комплексы, находятся под управленческим контролем. На сегодняшний день в основном во всех организациях идет контроль главных характеристик, которые связаны с производством и использованием программных продуктов (далее ПП), к которым относятся: время, финансовые средства, ресурсы и т.п. В связи с отсутствием возможности установления глубокого контроля требуется рост количества необоснованных решений, что в свою очередь увеличивает проектные и финансовые риски, которые связанны с разработкой и внедрением систем. В настоящее время существует не одно определение качества, которые имеют совместный характер. Наиболее распространенными являются:  определение 1 (ISO): Качество – представляет собой полноту свойств и характеристик ПП, процесса или услуги, обеспечивающие способность удовлетворять подразумеваемым или заявленным потребностям;  определение 2 (IEEE): Качество программного обеспечения – представляет собой степень, в которой оно обладает требуемой комбинацией свойств.1 1 Андон Ф.И., Суслов В.Ю., Коваль Г.И., Коротун Т.М. Основы качества программных систем.-Киев, Академпериодика.- 2002.-502с. 19

Качество ПО представляет собой совокупность свойств, которые характеризуют способность ПО удовлетворять потребности пользователя в соответствии с его предназначением. Управление качеством представляет собой систему экономических, организационных, правовых осуществляют для и технологических удовлетворения мероприятий, требований которые к качеству ПО в течение ЖЦ. Свойства программы представляет собой особенности, которые объективно свойственны программе, проявляющиеся в ее ЖЦ (разработке, применении и сопровождении).1 Определенному свойству соответствует одна или несколько характеристик ПО. Система измерений характеристик ПО представляет собой совокупность измеряемых характеристик, измерительных шкал и связей, установленных между ними, единиц измерения. Для ПО используют виды измерительных шкал, такие как: номинальные (категорийные), порядковые, интервальные. Номинальная (категорийная) шкала представляет собой фиксируемое наличие или отсутствие определенной характеристики свойства без учета градаций, что позволяет классифицировать программы по этому принципу. Порядковая шкала концентрирует отношение порядка, что разрешает ранжировать программы сравнительно определенного базового значения характеристик свойств. Интервальная шкала фиксирует не только лишь величину, но и отношение порядка, которая отличает значения характеристик между собой (интервал между значениями). Методы оценки характеристик ПО разделяют на группы, такие как: регистрационные, измерительные, расчетные, социологические, экспертные, традиционные. 1 Дж. Гарретт. Веб-Дизайн: книга Джесса Гаррета. Элементы опыта взаимодействия. СПб, СимволПлюс, 2008. 20

Свойства ПО можно разделить на группы: функциональные (это так называемые внешние) и конструктивные (внутренние). Внешние свойства, которые отражают точку зрения пользователей определяют качество ПО (рисунок 1.4). Для разработчиков ПО представляют интерес не только внешние, но и внутренние или конструктивные свойства, от которых зависит выполнение требований и восприятие его пользователями. Рисунок 1.4 - Группы свойств и характеристики программного обеспечения Характеристики качества отражают свойства, которые определяют качество ПО. Количественная оценка характеристик качества ПО используют для оценки иерархические системы измерений (рисунок 1.5). Два верхних и основных уровня иерархии измерений составляют критерии и факторы, 21

которые отражают функциональные характеристики ПО, а нижний уровень, к которым относятся оценочные элементы и метрики, представляют собой конструктивные характеристики, где от них зависит качество ПО. Рисунок. 1.5 - Факторы качества, отражающие полезность ПО Фактором можно назвать свойство, которое обеспечивает качество ПО. Когда оценивается качество учитываются не один фактор, а сразу несколько, с целью получения численной оценки. Критерий качества представляет собой численные показатели или признаки, которые характеризуется фактором оценки качества ПО. Для вычисления значений учитываются одна или несколько метрик. Метрика представляет собой меру количественной оценки качества ПО по определенно заданному критерию, систему или способ измерений качества ПО. Метрика может содержать оценочных элементов. 22 один или несколько

Оценочный элемент представляет собой измеримую характеристику ПО, которая имеет численное значение в избранной измерительной шкале. Показатель качества представляет собой численное значение критерия качества, которое определяет степень, характерное определённому свойству. (рисунок 1.6). Рисунок 1.6 - Модель измерений характеристик качества (по ГОСТ 28195-89) Сущность управления качеством в процессе разработки ПС можно разделить на следующие виды деятельности:  Обеспечение организационных качества. процедур и Подразумевает стандартов с отдельные целью множества создать ПО высокого качества.  Планирование качества. Предполагает выбор из этого множества соответствующего подмножества процедур адаптация их к данному проекту разработки ПО. 23 и стандартов и

 Контроль качества. Определение и проведение мероприятий, гарантирующее выполнение процедур и стандартов качества всеми членами команды разработчиков ПО.1 Таким образом, управление качеством предполагает возможность автономного контроля за процессом разработки программного средства (далее ПС). Контрольные проектные элементы, разработки ПС, являются основой проверяются на соответствие которые контроля целям проекта получают качества. и в Они стандартам. процессе тщательно Так как выполняемые работы по обеспечению и контролю качества в определенной степени независимы, то это предполагает возможность объективного взгляда на процесс разработки ПС, в связи с чем руководство компании может оперативно получить информацию о трудностях и проблемах, возникающие в работе над проектом. 1.4 Проблемные стороны современных методик и технологий оценки качества интерфейса программного продукта Несмотря на высокие показатели качества сегодняшних современных методик и технологий оценки качества интерфейса ПП существует и ряд их недостатков. В данной главе они будут проанализированы и перечислены. Роль поведенческих факторов в успехе программных продуктов растёт. UX-дизайн представляет главную роль в процессе коммуникации пользователей и ресурса. Проектирование интерфейсов позволяет уменьшить стоимость ошибок. Существует несколько оценок качества пользовательского интерфейса: рекомендации стандартов ГОСТ Р ИСО 14915–1-2010, ГОСТ Р ИСО 9241–210– 2012, ГОСТ 28195–89. 2 1 Оценка качества информационной системы. Критерии качества ИС [Электронный ресурс] / Электр. текст, дан. – Режим доступа: http://mylektsii.ru/6-136315.html, свободный. 2 Стив Круг. Как сделать сайт удобным. Юзабилити по методу Стива Круга. СПб, Питер, 2010, 208 стр. 24

ГОСТ 28195–89 используется для оценки качества программных продуктов. Например, оценочный элемент стандарта Н0102 «Возможность обработки ошибочных ситуаций» фактора «Надёжность программной системы» показывает степень покрытия реакциями и экранами интерфейсов контроля возникновения или сообщения об ошибке в системе, который обеспечивает обратную связь пользователя и используемого приложения. У стандарта ГОСТ 28195–89, есть ряд требований, которые сформировались пользовательским опытом:  оформление документации, понятности и корректности справочной информации;  язык приложения и контекстные подсказки;  скорость работы системы и индикации процесса работы;  устойчивость системы к обработке и возникновению ошибок;  стандартизация и унификация программных средств;  устойчивость системы к прерываниям;  простота навигации в рамках системы;  защита системы. Удобство применения в стандарте ГОСТ 28195–89 заключается в точности описания работы ИС в документации, без использования учёта особенности работы пользователей с системами. ГОСТ 28195–89 пренебрегает оценкой краткости технических описаний и контекстом их получения. Недостатками данного стандарта является отсутствие оценки пользовательской заинтересованности конечных потребителей при проектировании функционала ИС. ГОСТ Р ИСО 14915–2010 «Эргономика мультимедийных пользовательских интерфейсов». Данный стандарт ориентирован на то, чтобы обеспечить результативность, эффективность и повышение удовлетворенности пользователей от работы с большим количеством современных приложений. Данный стандарт разбирает: перспективные 25 характеристики, желания

пользователей, сенсорные ощущения, способы изучения и обмена информацией между потребителями ИС с целью получить оценку качества пользовательского интерфейса. Оценка качества интерфейсов согласно данному стандарту проходит через тестирования ИС, а экспертам предоставляется контрольный лист со определёнными критериями оценок. Но несмотря на точность описывания современных пользовательских интерфейсов и большим списком сценариев, представляющихся для тестирования, данный стандарт все же отличается и рядом недостатков, таких как:  отсутствием опциональных списков, которые в зависимости от назначения снабжены проектируемой системой;  необходимостью постоянного проведения пользовательского тестирования и результата опросов, требующих детального отбора сотрудников отдела тестирования и дополнительных затрат, где в иных случаях выгоднее бы была экспертная оценка;  отсутствием описания метода оценки интерфейсов. Также в 2012 году был принят ГОСТ Р ИСО 9241–210, описывающий при проектировании ПП человеко-ориентированный подход. Данный подход призван поставить в центр внимания прежде всего нужды пользователей ИС, где уже сами пользователи являются неотъемлемыми участниками процесса разработки. Также в стандарте учтены и личные интересы пользователей, их эмоциональные аспекты, удовлетворенность от работы и отсутствие однообразия при решении различных задач. Недостаток данного стандарта «Эргономика взаимодействия человексистема» заключается в необходимости измерения и учета эффективности, результативности пользовательских интерфейсов без предложений способа измерения интерфейса. Таким образом, существующие системы оценок пользовательских интерфейсов, которые предлагаются российскими стандартами, имеют ряд недостатков, не позволяющие в совершенной мере оценить удовлетворенность 26

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

 метод оценивания;  метрики и вспомогательные инструменты. Оценить качество продукта нет возможности в случае, если нет данных о требованиях и критериях качества от пользователя и процесс измерения продуктов, ресурсов, процессов не определен и отсутствует процесс оценки продуктов в ходе жизненного цикла.1 Назначение процесса оценки продуктов - единственного из процессов поддержки ЖЦ, которые определенны в стандарте ISO/IEC 12207заключается в том, чтобы «гарантировать путем систематического измерения и оценивания, что продукт удовлетворяет предполагаемым и установленным требованиям пользователей к продукту. В итоге после успешно выполненного процесса:  будут определены требования, которые касаются проведения оценивания;  будут установлены критерии оценки ПП;  будут определены методы выполнения оценивания и все действия в рамках этих методов будут соответствующим образом выполняться;  данные измерений будут собираться, а результат применения метрик будет оцениваться по отношению к определенным критериям;  итоги деятельности по оценке ПП будут доступны для всех заинтересованных сторон процесса.2 На этапах разработки идет оценка промежуточных (рабочих) продуктов ПС и конечного программного продукта. Цель оценки качества уже рабочих продуктов является:  принять различные решения о приеме промежуточного ПП у соисполнителей;  принять решение об окончании одного из процессов и сроке передачи ПП на следующий процесс; 1 ИНТУИТ [Электронный ресурс] / Оценка качества информационных систем (ИС) – Режим доступа: https://www.intuit.ru/studies/courses/651/507/lecture/11551, свободный. 2 Информационные технологии [Электронный ресурс] / Оценка качества информационных систем – Режим доступа: https://studme.org/59750/informatika/otsenka_kachestva_informatsionnyh_sistem, свободный. 28

 сделать выводы или анализ предварительной оценки качества уже завершенного ПП;  в целях управления и контроля процессами разработки ПС собрать информацию о промежуточных продуктах. Целью оценки качества уже конечного программного продукта является:  принять решения о приеме ПП;  принять решение о сроках выдачи ПП;  сравнить ПП с иными продуктами;  выбрать продукт из массы альтернативных ПП;  оценить положительный и отрицательный результат от использования ПП. Процесс выполнения оценки ПС отвечает требованиям ISO/IEC 12207 и регламентируется стандартом ISO/IEC 14598. Данный стандарт предполагает оценку ПП пошагово по процедурам и ориентирован на использование обобщенной модели качества ПС, который представлен в стандарте ISO/IEC 9126 (Приложение А). Процесс оценки устанавливает определенные требования к оцениванию типов ПП и методам измерения, что служит процессом интеграции и этапами разработки и с различными другими процессами, для которых необходима оценка. Например, для оценивания продуктов независимыми оценщиками. Для оценки ПП заказчиками, разработчиками, потребителями, независимыми оценщиками есть отдельные части стандарта оценивания. Помимо наличия определенных требований к оцениванию могут выделять и уровни оценивания для различных характеристик качества, в зависимости от уровней целостности оцениваемой ПС, а также компонентов. Требования выше к уровню значений отдельных характеристик и строже к методам оценивания, если выше заданный уровень целостности ПС. В стандарте определяются уровни оценивания (от А — высшего до D низшего), в связи с учетом риска в сфере безопасности функционирования 29

(угрозы жизни людей), защиты информации (угрозы потери информации), экон омики (угрозы финансовых убытков), среды функционирования (угрозы разрушения (не восстановления) среды эксплуатации ПС). В зависимости от уровня оценивания, который устанавливается для отдельной из характеристик качества ПП, выбирается метод или условия оценивания и измерения. По каждой отдельной шкале идет определение коэффициентов весомости отдельной характеристики, данный анализ производится экспертным путем. Наиболее строгой схемой присваивания параметров весомости характеристикам дана в Межгосударственном стандарте ГОСТ 28195. Стандарт определяет установленные значения параметров весомости для каждой подхарактеристики и зависит от стадии ЖЦ ПС, а также от класса ПС. Таким образом, были проанализированы подходы к диагностике состояния программного продукта. Определено назначение процесса оценки продуктов, цели оценки качества ИС согласно анализу различных стандартов. 30

2 Анализ предметной области и технологий построения систем 2.1 Сравнительная оценка качества информационной системы В исследовании выпускной квалификационной работы в качестве примера программного продукта была рассмотрена информационная система страховой деятельности, поэтому стоит задача в необходимости рассмотрения подробнее сферу управления в страховании. Для обоснования предлагаемого проекта информационной системы было проведено сравнение оценки качества информационных систем страховой деятельности с помощью метода анализа иерархий. Реализацию данного метода позволила провести разработанная сотрудниками кафедры прикладной информатики и информационных технологий к.т.н пофессором Ломакиным В.В. и к.т.н. Лифиренко М.В., автоматизированная система СППР «Решение». Анализ проведен на основе требований к новой методике количественной оценки пользовательского интерфейса, предъявляемых к информационной системе СД, такими как:  надёжность представляет возможность ПП противостоять различным сбоям, которые были совершены пользователями, разработчиками или в ходе воздействия внешних факторов;  единообразие представляет возможность использовать единую цветовую и шрифтовую схемы, однородных компонентов, интерфейсов и принципов с целью осуществления сходных или одинаковых функций;  очевидность состояния системы представляет собой возможность представления этапа работы программы или приложения с помощью механизмов обратной связи;  гибкость представляет способность приложения адаптироваться под разнообразные платформы, форм-факторы пользователя; 31 или нужды конкретного

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

действенность способов создания эмоциональных привязок пользователей и приложений;  язык приложения представляет собой определенный словарь приложений, а также стилистику уже применяемых фраз и степень того, насколько они соответствуют ожиданиям целевой аудитории;  базируется общественное окружение представляет собой фактор, который на присутствие у приложений неформальных сообществ в социальных сетях и на иных ресурсах. Каждому требованию ИС СД поставлена оценочная характеристика. После выделения необходимых критериев в среде СППР были выявлены альтернативы представленных информационных систем. На рисунке 2.1-2.2 представлена программная среда (графическая панель) всех введенных данных и заполненных необходимыми полями. За основы взяты такие альтернативы, как: 1) UNICUS - обозначена в графической панели, как «Система №1». 2) Carabi-страхование - обозначена в графической панели, как «Система №3». 3) ИНЭК-страховщик - обозначена в графической панели, как «Система №4». Рисунок 2.1- Иерархия принятия решения 33

Рисунок 2.2- Иерархия принятия решения После чего была проведена операция «Сравнение решения по всем критериям». На рисунке рисунок 2.3 представлено решение по критерию «Надежность», где также расставлены приоритеты. Рисунок 2.3 – Матрица сравнения по критерию «Надежность» Сравнение по всем рассмотренным критериям представлены на рисунке 2.4, где указаны приоритеты каждого критерия. 34

Рисунок 2.4 – Матрица сравнения критериев После выполнения всех нужных процедур необходимо вывести все результаты представленных решений в графическом виде. Результы данного исследования таковы: «Система №1» составляет 23,3%; «Система №2» составляет 47,9%; «Система №3» составляет 15,3%; «Система №4» составляет 13,5%; 35

Рисунок 2.5 – Результаты выбора ИС СД Согласно проведенным исследованиям приоритетной является ИС СД №2, значение которой составляют 47,9%. Данная альтернатива имеет больший процент среди других за счет эффективности необходимых выше описаннных критериев. Согласно результату наибольший приоритеты имеет следующие критерии:  «Выгода от использования» состовляет 0,110;  «Поддержка» состовляет 0,106;  «Общественное окружение» состовляет 0,104;  «Функциональность» состовляет 0,101;  «Очевидность состояния системы» состовялет 0,099;  «Удовлетворенность» состовляет 0,099;  «Вовлеченность» состовляет 0,092;  «Язык приложения» состовляет 0,088;  «Гибкость» состоявляет 0,049;  «Качество контента» сотовляет 0,044; 36

 «Когнитивная простота» состовляет 0,037;  «Надежность» состовляет 0,028;  «Эмоциональность» состовляет 0,015;  «Единообразие» состовляет 0,015;  «Эргономическая простота» состоявляет 0,015. В результате пользовательского данная модель взаимодействия позволяет с системами оценить как качество с привлечением к тестированию целевой аудитории продукта, так и посредством экспертных оценок. 2.2 Построение исходной концептуальной модели предметной области Процесс проектирования информационной системы представляет процесс принятия проектно-конструкторских решений, которые направлены на получение описания системы, удовлетворяющей требованиям. Целью проектирования страхования является учет и оценивания клиентов информационной страховой компании, системы ведение документации, а также ведение финансовых движений страховой компании. Концептуальное собой начальную проектирование технических стадию проектирования, в ходе систем представляет которой начинают определяться последующие облики решения, а также проводится исследование и согласование параметров созданных технических решений с возможной их организацией. Разработанной информационной системой страхования пользуются фирмы, которые занимаются страхованием граждан и их имущества. Если оценить данную информационную систему со стороны пользователя, то рассматриваемая ИС должна быть прежде всего интуитивно понятна, хранить всю необходимую информацию для страхования граждан и их имущества, а также быть простой в использовании. 37

Задача страховой компании заключается в отслеживании финансовой деятельности компании. Компания имеет различные филиалы по стране. Каждый филиал имеет название, адрес и телефон. Деятельность компании заключается в том, что в организацию обращаются различные лица с целью заключить договор о страховании. В зависимости от принимаемых на страхование объектов и страхуемых рисков, договор заключается по определенному виду страхования (например, страхование автотранспорта от угона, страхование домашнего имущества или добровольное медицинское страхование). При заключении договора фиксируется дата заключения, страховая сумма, вид страхования, тарифная ставка и филиал, в котором заключался договор. Разработка и внедрение автоматизированных информационных систем страховой деятельности выполняются с целью повышения эффективности управления СД компании за счет обеспечения руководителей и специалистов страховых компаний информацией в необходимом объеме и качестве, а также реализации стандартов информационных технологий управления на основе:  поддержки принятия управленческих решений;  снижения издержек управления страховой деятельностью;  создания интегрированной БД;  обеспечения защиты информационных ресурсов;  поддержки электронного документооборота;  интеграции с внешними информационными системами;  повышения информационной культуры управленческого труда. Необходимость автоматизации управления страхового бизнеса обусловлено: большим объемом информации, требованиями к оперативному получению полной и точно предоставленной информации, расширением масштабов и функций управления СД. Видами ИС СД являются: личное страхование и имущественное. Личное страхование делится на:  страхование жизни; 38

 страхование жизни на случай смерти, дожития до определенного возраста или срока наступления иного события;  пенсионное страхование и т.д.;  страхование от несчастных случаев и болезней;  медицинское страхование. Имущественное страхование делится на:  страхование имущества;  страхование средств наземного, воздушного и водного транспорта;  страхование грузов;  сельхоз страхование;  страхование имущества юридических и физических лиц;  страхование гражданской ответственности: а) владельцев средств наземного, воздушного и водного транспорта; б) организаций, эксплуатирующих опасные объекты; в) за причинение вреда третьим лицам и т.п; г) страхование предпринимательских рисков. По форме проведения страхование бывает: обязательное и добровольное. Наглядное представление видов страхования представлено на рисунке 2.6. 39

Рисунок 2.6 – Виды страхования Изолированное выполнение задач и функций оперативного управления страховой деятельностью, отсутствие функциональной и информационной интеграции АРМов и внешней среды делают невозможным дальнейшее развитие страховой деятельности с применением ИС СД данной формы организации. Локальная автоматизация отдельных отделов и служб позволяет упростить выполнение тех или иных операций, но не оказывает никакой помощи руководству страховой компании для подготовки аналитических отчетов, моделирования управленческих решений из-за отсутствия единого информационного пространства, которое является основой подготовки управленческих решений. ИС СД поддерживает ряд основных функции деятельности в области страхования и вспомогательные функции управления, такие как бухгалтерский учет, финансовый анализ, управление кадрами. В случае увеличения численности сотрудников страховых компаний возрастают масштабы всей деятельности компании. Из-за увеличения масштабов ИС СД необходима приведение объектов функционального 40 назначения к единообразию

информационных технологий, программных и технических средств обработки информации. Локальные вычислительные сети (далее ЛВС), компьютерная сеть являются обязательными компонентами ИС СД. Они позволяют улучшить характеристики информации и информационных процессов, а также обеспечить полноту и целостность данных для принятия важных управленческих решений, оперативно получить и обработать данные с высоким уровнем надежности, достоверности и актуальности информации. С ростом масштабов деятельности и повышением требований к эффективности управления страхового бизнеса появляются причины для создания КИС СД. Этому способствуют следующие характерные черты:  осуществиться переход к распределенной обработке данных (использование компьютерных сетей, интернет, выход в Интернет);  применятся разнородные вычислительные машины - это серверы, рабочие станции, ноутбуки (аппаратная);  будут интегрированы программные средства обработки данных;  расширятся функции автоматизации управления;  осуществится создание и ведение интегрированной БД - основы единого информационного пространства для принятия управленческих решений. В корпоративной информационной среде созданы сетевые ресурсы (принтеры, серверы печати, факс-модемы, БД, общие приложения), доступ к которым возможен с рабочих станций. Это позволит существенно сэкономить финансовые средства, повысить информационную и технологическую "вооруженность" каждого АРМа, обеспечить мобильностью специалистов страховой компании. Прогресс в сфере технических средств обработки данных и средств коммуникаций (удешевление технических комплексов, новые технологии WiFi, WAP и GPRS и др.) позволили реализовать: 41

 мобильное подключение переносных компьютеров (ноутбуков) к Интернет/интранет (корпоративной сети);  поддержку частных сетей - VPN (Virtual Private Network). В корпоративную информационную ИС СД входят две системы обработки данных, такие как:  OLTP (On-Line Transaction Processing) - система оперативной транзакционной обработки данных;  OLAP (On-Line Analytical Processing) - система оперативной аналитической обработки данных. Характеристиками систем являются:  многочисленность пользователей;  транзакционный характер обработки данных. То есть обработка приложении разбивается на отдельные транзакции. Транзакция представляет совокупность действий, которые переводят БД из одного целостного состояния в другое. В случае возникновения ошибок или отказов выполняется откат транзакции и восстановление БД в ее исходное состояние. То есть таким образом удастся поддержать надежность и высокую производительность обработки информации:  большие объемы собираемых, передаваемых хранимых и обрабатываемых данных;  полный состав форм входной и выходной информации, схем документооборота. Функциональная структура ИС СД включает в себя типовой комплекс задач, таких как: 1) Ведение нормативно-справочной базы договоров страхования (справочники, классификаторы технико-экономической информации, тарифы страхования). 2) Стратегическое планирование деятельности страховой компании. 3) Формирование и ведение договоров страхования (перестрахования). 4) Расчет комиссионных. 42

5) Учет формирования страхового фонда. 6) Учет расчетов со страхователем (уплата страховых премий, выплат по страховым событиям, расторжение договора страхования). 7) Бухгалтерский учет деятельности страховой компании. 8) Анализ финансового состояния страховой компании. 9) Налоговый учет страховой деятельности. 10) Сервисные функции (импорт и экспорт данных, страховое копирование, восстановление БД). Основой конфигурирования функциональной и организационной структуры ИС СД является модульный подход, который обеспечивает простоту и экономичность модернизации функциональной структуры. Моделирование данных предметной области является основой проектирования структуры БД. Информационно-логическая модель (далее ИЛМ), которая не ориентирована на какое-либо программное средство создания и ведения БД является начальной стадией для представления данных предметной области. ИЛМ служит интерфейсом между "заказчиком" и "разработчиком" ИС СД, с целью более лучшего понимания информационных потребностей приложений. ИЛМ состоит из структурных связей и информационных объектов. Для представления ИЛМ используется ER-диаграмма ("сущность" - "связь"). Выделены типовые сущности в рассматриваемой предметной области. На рисунке 2.6 представлена типовая ИЛМ для ИС СД. Данная модель содержит следующие информационные объекты, которые описывают такие сущности как: 1) Страховой фонд - включена сумма страховых взносов, которая находится в управлении у страховой компании. 2) Страхователь - является физическое или юридическое лицо. 3) Договор страхования - документ, который обладает юридической силой и содержит все необходимые реквизиты для придания юридической силы, такие как: номер договора, 43 дата заключения, срок действия,

квалификация страхового случая, стоимость объекта страхования, условия выплат страховой премии, порядок расчетов, страховой случай, дата завершения договора и другое. 4) Вид страхования – представлена в виде нормативной базы для расчетов страховой премии, тарифной ставки. 5) Страховые выплаты – в который входят: дата, сумма, платежный документ. 6) Страховые взносы – входят: дата, сумма взноса, платежный документ. Рисунок 2.7 - Типовая информационно-логическая модель для ИС страховой деятельности В ходе анализа предметной области ИС СД были выделены сущности и определены первоначальные требования к информационной системе, определены виды ИС СД, функции, основные черты КИС СД, сетевые ресурсы, средства коммуникации, характеристики OLTP и OLAP систем, задачи функциональной структуры ИС СД, построена типовая информационнологическая модель для ИС страховой деятельности. Разработанная концептуальная модель данных предприятия служит источником информации для начала проектирования базы данных. 44

2.3 Разработка структуры базы данных и интерфейса информационной системы страховой деятельности Для разработки структуры базы данных информационной системы СД применены возможности программного продукта ArisExpress. ARISExpress моделирования – это методология бизнес-процессов и программный организаций. При продукт для проектировании использовалась ER-модель данных (Data model), с её помощью можно выделить главные сущности и обозначить связи, которые могут устанавливаться между данными сущностями. Основными элементами являются:  Entity - сущность (таблица);  Attributes - атрибут сущности (поле таблицы);  Primary Key - уникальный атрибут сущности (первичный ключ таблицы);  Foreign Key - внешний ключ таблицы;  Relationship - отношения между сущностями (связь между таблицами). При проектировании ИС СД была создана структура базы данных, разработанная в инструментальном средстве ArisExpress, состоящая из следующих 12 таблиц: «БСО», «Вид страхования», «Договор страхования», «Документы об оплате», «Заявления», «Клиенты», «Клиенты/Страхование», «Пакет документов», «Страхователь», «Предпринимательские «Страхователь/Страхование», риски», которые «Страхование», представлены таблицах 2.1-2.3. Таблица 2.1 - Содержимое таблицы «БСО» № 1 Имя поля Описание Тип данных 1 2 3 Номер БСО Идентификатор номера БСО 45 Числовой в

продолжение таблицы 2.1 1 2 3 2 Дата создания Информация о дате создания бланка 3 ФИО сотрудника Информация о фамилии, имени, отчестве Короткий текст сотрудника 4 Номер договора Информация о номере договора Числовой 5 Серия договора Информация о серии договора Короткий текст 6 Дата получения Информация о дате получения бланка Дата и время 7 Статус Короткий текст Информация о статусе бланка Дата и время Таблица «БСО» содержит всю необходимую информацию о бланке строгой отчетности. Таблица 2.2 – Содержимое таблицы «Вид страхования» № Имя поля Описание Тип данных 1 Код вида страхования Идентификатор кода вида страхования Числовой 2 Наименование страхования Информация о виде страхования Короткий текст 3 Срок действия Информация о сроке действия страховки страхования 4 Процент страхового Информация о сумме (проценте) Числовой взноса от суммы страхового взноса, полученной от страхования страхования Дата и время Таблица «Вид страхования» содержит информацию о виде страхования, его наименовании, сроке действия и проценте страхового взноса. 46

Таблица 2.3 - Содержимое таблицы «Договор страхования» № Имя поля Описание Тип данных 1 Номер договора бланка Идентификатор договора номера 2 Серия договора бланка Информация о серии бланка договора 3 Дата заключения Информация договора 4 Статус договора Информация о статусе договора 5 Дата последнего Информация о дате изменения изменения договора 6 Страховая премия Информация о начисленной страховой Числовой премии 7 Страховая сумма Информация о начисленной страховой Числовой сумме 8 Дополнительные условия Информация об дополнительных условиях 9 Номер заявления Информация о номере заявления 10 Номер документа об Информация о номере документа об Числовой оплате оплате 11 Тип заявления о сроке бланка Числовой Короткий текст заключения Дата и время Короткий текст последнего Дата и время отдельных Короткий текст Информация о типе заявления Числовой Короткий текст Таблица «Договор страхования» содержит информацию о серии и номере бланка, дате заключения и изменения договора, статусе, страховой премии и сумме, номер заявления, номер документа об оплате и тип заявления. Таблица 2.4 - Содержимое таблицы «Документы об оплате» № Имя поля Описание Тип данных 1 2 3 1 Номер документа об Идентификатор номера документа об Числовой оплате оплате 2 Дата оплаты Информация о дате оплаты страховки 3 Сумма Информация о выплаченной сумме по Числовой страхованию 47 Дата и время

продолжение таблицы 2.4 1 2 3 4 ФИО кассира Информация о ФИО кассира, Короткий текст принимающего сумму оплаты за страхование 5 ФИО плательщика Информация о ФИО плательщика, Короткий текст заплатившего сумму за страхование 6 Серия паспорта Информация плательщика плательщика о серии паспорта Числовой 7 Номер паспорта Информация плательщика плательщика о номере паспорта Числовой 8 Тип документа Информация о типе документа оплаты Короткий текст Таблица «Документы об оплате» содержит информацию о номере документа об оплате, дате, сумме оплаты, ФИО кассира, ФИО плательщика, серия и номер паспорта плательщика, типе документа, номере договора об оплате. Таблица 2.5 - Содержимое таблицы «Заявление». № Имя поля Описание Тип данных 1 Номер заявления Идентификатор номера заявления Числовой 2 Дата принятия Информация о дате принятия заявления Дата и время 3 Код страхователя Информация о коде страхователя Числовой 4 ФИО сотрудника Информация о ФИО принявшего заявление 5 Срок страхования Информация о сроке страхования Дата и время 6 ИНН Информация о номере ИНН Числовой 7 Порядок уплаты Информация о страховой премии страховой премии сотрудника, Короткий текст порядке уплаты Короткий текст Таблица «Заявление» содержит информацию о номере заявления, дате принятия заявления, коде страхователя, ФИО сотрудника, принявшего заявление, срок страхования, ИНН, порядок уплаты страховой премии. 48

Таблица 2.6 - Содержимое таблицы «Клиенты». № Имя поля Описание Тип данных 1 Код клиента Идентификатор о коде клиента Числовой 2 Фамилия Информация о фамилии клиента Короткий текст 3 Имя Информация о имени клиента Короткий текст 4 Отчество Информация о отчестве клиента Короткий текст 5 Паспорт Информация о паспортных данных Короткий текст Таблица «Клиенты» содержит информацию о фамилии, имени, отчестве и паспорте клиента. Таблица 2.7 - Содержимое таблицы «Клиенты/Страхование». № Имя поля Описание Тип данных 1 Код клиента Идентификатор о коде клиента Числовой 2 Код страхования Идентификатор о коде страхования Числовой Таблица «Клиенты/Страхование» содержит информацию о коде клиента и страхования. Таблица 2.8 - Содержимое таблицы «Пакет документов». № Имя поля Описание Тип данных 1 2 3 1 Номер документов пакета Идентификатор документов о номере 2 Отчет о финансовом Информация, содержащая отчет о Длинный текст состоянии финансовом по состоянию пакетов документов 3 Бизнес-план Информация о бизнес-плане 49 пакета Числовой Длинный текст

продолжение таблицы 2.8 1 2 3 4 Копия договора контрагентами с Информация с копиями документов с Короткий текст контрагентами 5 Отчет о финансовом Информация, содержащая отчет о Длинный текст состоянии финансовом по состоянию пакетов документов 6 Копия лицензии 7 Копия свидетельства о Информация с копиями свидетельств о Короткий текст регистрации регистрации документов 8 Копия свидетельства о Информация с копиями свидетельств о Короткий текст поставке на учет поставке на учет 9 Копия учредительных Информация с копиями учредительных Короткий текст документов документов Информация с копиями лицензий Короткий текст Таблица «Пакет документов» содержит информацию о номере пакетов, отчете о финансовом состоянии, бизнес-план, копии договора с контрагентами, лицензии, свидетельства о регистрации, свидетельства о поставке на учет, учредительных документов. Таблица 2.9 - Содержимое таблицы «Предпринимательские риски». № Имя поля Описание Идентификатор о коде риска Тип данных 1 Код риска 2 Возможные убытки в Информация о возможных убытках, Короткий текст процессе возникших в процессе деятельности деятельности 3 Нарушение обязательств контрагентами Информация о возможных нарушениях Короткий текст обязательств контрагентами 4 Номер заявления Информация о номере заявления 50 Числовой Числовой

Таблица «Предпринимательские риски» документов содержит информацию о возможных убытках, которые могут возникнуть в процессе деятельности, нарушениях обязательств контрагентами, номере заявления. Таблица 2.10 - Содержимое таблицы «Страхование». № Имя поля Описание Тип данных 1 2 3 1 Код страхования Идентификатор о коде страхования Числовой 2 Код клиента Информация о коде клиента Числовой 3 Код вида страхования Информация о коде вида страхования Числовой 4 Сумма страхования Информация о сумме страхования Числовой 5 Дата страхования начала Информация о дате документов страхования заключения Дата и время Таблица «Страхование» содержит информацию о коде страхования, клиента, виде страхования, страхователя, оформившего договор, сумме страхования, дате начала страхования, ИНН. Таблица 2.11- Содержимое таблицы «Страхователь». № Имя поля Описание Тип данных 1 2 3 1 Код страхователя ID кода страхователя Числовой 2 ФИО Информация о ФИО страхователя Короткий текст 3 Номер документов 4 Номер свидетельства Информация о номере свидетельства о Числовой о регистрации регистрации 5 Дата выдачи полиса Информация о дате выдачи полиса Дата и время 6 Офис Информация об адресе офиса Короткий текст 7 Телефон Информация о телефоне Числовой пакета Информация о номере документов 51 Числовой

Таблица «Страхователь» содержит информацию о ФИО, дате выдачи полиса, номере пакета документов, номере свидетельства о регистрации, офисе, телефоне. Таблица 2.12 - Содержимое таблицы «Страхователь/Страхование». № Имя поля Описание Тип данных 1 Код страхователя Идентификатор о коде страхователя Числовой 2 Код страхования Идентификатор о коде страхования Числовой Таблица «Страхователь/Страхование» содержит информацию о коде страхователя и страхования. Общая структура таблиц представлена в приложении Б. Каждый филиал осуществляет страхования клиентов и заключает с ними договоры, исходя из этого связь между сущностями «договор» и «филиал». Каждый договор заключается по определенному виду страхования. Также в рамках данного этапа был разработан интерфейс ИС СД, который содержит следующие модули: договоры страхования, клиенты, оплаты, модуль БСО, который включает заявки БСО и справочники, справочники, отчеты, комиссионные вознаграждения, настройки. Наглядное представление интерфейса системы представлено на рисунке 2.8. 52

Рисунок 2.8 – Интерфейс главной страницы ИС СД На рисунке 2.9 представлен интерфейс модуля БСО, заявки БСО. В рамках данного модуля представляется возможность создать заявку БСО. Есть табличное представление внесенных данных в заявку, которое включает в себя: номер БСО, дата создания, ФИО сотрудника, номер договора, серия БСО, Дата получения, Статус. На форме также присутствует поисковая форма в виде фильтра для добавления данных. 53

Рисунок 2.9 – Интерфейс ИС СД, модуль «Заявки БСО» В ходе данного этапа была разработана структура базы данных. Данная модель показывает обеспечение высокой эффективности функционирования системы. Также в рамках данного этапа был разработан интерфейс ИС СД. 2.4 Моделирование бизнес-процессов информационной системы страховой деятельности Для разработки модели ИС СД были разработаны бизнес-модели ИС СД. Для разработки бизнес-модели ИС СД применены возможности программного продукта Visio. 54

Visio представляет собой векторный графический редактор, диаграмм и блок-схем для Windows, моделирования, анализа, документирования бизнеспроцессов, а также позволяет создавать нотации IDEF0, IDEF3, DFD. При проектировании системы была создана бизнес-модель процесса, разработанная при помощи нотации IDEF0. С помощью данного стандарта была разработана бизнес-модель процесса «Страхование», где:  условием начала выполнения бизнес-процесса является заявление о страховании, пакет необходимых документов, информация о страхователе;  документами, необходимыми для реализации бизнес-процесса является законодательство РФ;  действующими лицами, принимающими участие в выполнении бизнес-процесса, являются: сотрудники страховой компании;  результатами выполнения бизнес-процесса, является заключённый договор страхования;  целью данного бизнес-процесса является рассмотрение процесса страхования граждан. В систему поступает от граждан заявление о необходимом страховании, пакет документов и необходимая информация о страхователе. На функционирование системы оказывают влияние: законодательство РФ, гражданский кодекс, ФЗ «О страховом деле», «Правила страхования. Механизмами, влияющие на работу, являются: сотрудники страховой компании, клиенты. Выходом бизнес-процесса является заключенный договор страхования. 55

Рисунок 2.10 – Модель бизнес-процесса «Страхование» Декомпозиция процесса «Страхование» представлена на рисунке в приложении В. Разработанный Процесс состоит из: 1) Процесса «Анализирование данных». На вход поступает заявление о страховании, пакет документов, информация о страхователе, к управлению процесса относится: законодательство РФ. Механизмами процесса являются: сотрудники страховой компании. На выходе процесса разрешение на страхование. 56

2) Процесса «Согласование условий договора». На вход поступает разрешение на страхование, к управлению процесса относится: ФЗ «О страховом деле в РФ». Механизмами процесса являются: сотрудники страховой компании. На выходе процесса: дополнительная информация. 3) Процесса «Заполнение полей БД учета документов страхования». На вход поступает заявление о страховании, пакет документов, информация о страхователе, дополнительная информация, к управлению процесса относится: законодательство РФ. На выходе процесса: обработанные данные. Механизмами процесса являются: сотрудники страховой компании. 4) Процесса «Формирование договора и печать». На входе процесса: обработанные данные, к управлению процесса относится: правила страхования. На выходе процесса: бланк договора. Механизмами процесса являются: сотрудники страховой компании. 5) Процесса «Проверка и подписание договора». На вход поступает: бланк договора, к управлению процесса относится: гражданский кодекс. Механизмами процесса являются: сотрудники страховой компании, клиент. На выходе процесса: договор страхования. Декомпозиция процесса «Формирование договора и печать» представлена в приложении Г. Разработанный Процесс состоит из: 1) Процесса «Проверка объекта страхования». На вход поступают: документы клиента. Механизмам процесса являются: страховщик. На выходе процесса: отказ от страхования, одобрение страхования. 2) Процесса «Заполнение страхового полиса». На вход поступают: одобрение страхования, к управлению процесса относится: решение клиента. Механизмам процесса являются: страховщик. На выходе процесса: страховой полис неподписанный. 57

3) Процесса «Прием оплаты». На вход поступает: страховой полис неподписанный, данные клиента. Механизмам процесса являются: кассир, страховщик, клиент. На выходе процесса: страховой полис с отметкой об оплате. 4) Процесса «Подпись и выдача страхового полиса». На вход поступают: страховой полис с отметкой об оплате. Механизмам процесса являются: страховщик. На выходе процесса: страховой полис, копия страхового полиса. 5) Процесса «Помещение копии страхового полиса в архив». На вход поступает: копия страхового полиса. Механизмам процесса являются: страховщик. Также необходимо разработать алгоритм работы данной ИС. В приложении Д представлен алгоритм работы информационной ИС СД. Система может обрабатывать заявки, поступающих от клиентов на вид страхования. Принимать заявки и проверять их на соответствие всех требований, в случае несоответствия, также возможно провести исправление. Система предусматривает отправку полисов. После выполнения всех этапов будет сформулирован полис на страхование. В результате данного этапа проектирования информационной системы страховой деятельности «Страхования», были декомпозиция разработаны процесса бизнес-модели «Страхования», процессов декомпозиция процесса «Оформление договора страхования», а также алгоритм работы системы. 58

3 Разработка методики оценки качества взаимодействия работы программного продукта и пользователя с использованием UX-метрик 3.1 Систематизация критериев оценки функций программного продукта При проектировании ИС СД необходимо систематизировать критерии оценки функций рассматриваемого программного продукта. Согласно выделенным критериям, функций выделен ряд основных задач, которые выполняет ИС СД:  Процесс заключения договора. Подразумевает проверку всех расчётов, комиссий, случаев страховых выплат, проверка договоров по страхователям, заключение и выдача всех необходимых договоров, а также занесение информации в БД.  Заключение дополнительного договора. В случае изменения условий по договору, по объекту страхования с учетом основного договора занесение данных в БД.  Заключение договора перестрахования. Подразумевает перерасчет комиссионных вознаграждений, сопоставление информации, занесение в БД.  Внесение страховой премии (или ее части). Подразумевает перевод денежных средств по счетам, в случае, когда есть перестрахование необходимы расчеты с перестраховщиками.  Окончание договора страхования. Занесение информации в БД с целью сформировать резервы и другие расчеты.  Наступление страхового события. Проведение выплат, расчеты возмещений, различные перерасчеты по договорам или его прекращение, вод базы страховых событий.  Расторжение договора страхования. Подразумевает, чтобы все расчеты со страхователем были завершены, проводка денежных средств, внесение изменений в БД. 59

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

3.2 Разработка требований к техническому обеспечению Формализация характеристик качества и методологий их оценки является одной из главных проблем, обеспечивающая качество ПС. Для того, чтобы определить качество функционирования ИС СД, наличие технических возможностей ПС к совершенствованию, взаимодействию и развитию нужно использовать стандарты, применяемые в области оценки характеристик их качества. Как было ранее определено, рассматриваемым стандартом является ISO 9126. Для начала необходимо определить предназначение ИС СД. Рассматриваемая ИС СД предназначена для использования пользователями отдела страхования граждан. Задача заключается в оценке качества программы страхования, для определения недостатков системы с целью повышения оперативности, производительности, удобства, доступности ИС. Для достижения поставленных целей информационная система СД должна включать в себя следующие функциональные требования:  автоматизированный контроль за соблюдением законодательства при оформлении документов;  повышение оперативности обработки информации;  снижение трудоемкости операций по страхованию имущества граждан;  уменьшение числа ошибок при страховании имущества граждан;  уменьшение сведения учета невостребованной информации;  повышение удобства работы за счет разработанных форм работы с системой;  повышение уровня организации работников;  обеспечение более высокого уровня функциональности, гибкости, надежности и удобства использования ИС СД. Надежность системы должна обеспечиваться на уровне используемых аппаратных и программных средств. 61 Данный уровень достигается

определенным контролем входных данных, за обработкой и проверкой верности выходных форм. В ИС СД будет обеспечена информационная совместимость с популярными приложениями ОС Windows (Word, Excel, Access). Автоматически будет обеспечиваться программная совместимость в связи с использованием ПС. Совместимость будет обеспечена конструктивно (на этапе их создания), с такими программами как: Delphi, Access и т.д. Система будет реализована под операционной системой Windows. Таким образом, предназначение разрабатываемому в рамках рассматриваемой данного ИС программному СД, этапа было основные обеспечению, определено требования к информационная совместимость с приложениями операционной системы. 3.3 Разработка модели оценки качества программного продукта Высокое качество ИС СД является прежде всего залогом успешного ведения бизнеса компании. На сегодняшний день наиболее используемой и распространенной является многоуровневая модель качества ПО стандарта ISO 9126. В рамках данной главы была разработана методика с применением данного стандарта к оценке качества программного продукта. Назначение данной модели заключается в проверке полноты определения требований в ТЗ, идентификации требований, целей проекта и испытаний к ПС. Общее представление оценки качества ИС СД представлено на рисунке 3.1. 62

Рисунок 3.1 – Шаги оценки качества ИС СД. На начальном этапе были определены программного продукта. Прежде всего к требования к ним относится: качеству понятный пользовательский интерфейс, простота в работе с ИС, работоспособность всех прикладных компонентов, возможность самостоятельной проверки корректной работы приложений (тестирование). Исходя из того, что «идеальная система» имеет 20 баллов, можно определить степень качества ИС СД по следующим критериям оценки качества:  высокая, если k от 0,7 до 1;  средняя при k от 0,5 до 0,7;  низкая при k менее 0,5. 63

Таблица 3.1 - Оценка качества информационной системы Характеристика Промежуточная характеристика Детальная характеристика Наличие (1) Отсутствие (0) 1 2 3 4 1 1.1. пригодность 1.1.1-соответствие содержания выходной информации согласно требованиям пользователей 1.1.2-соответствие исходной информации, которая используется в компании 1 2.1.1-соответствие ИС требованиям защиты от предумышленных угроз 0 2.1.2-возможность эффективно и оперативно восстановить данные при угрозах 1 2.2.1-наличие средств возможности восстановления данных при ошибке на входе 0 2.2.2-наличие средств восстановления при сбоях оборудования 0 3.1.1-возможность изучения ИС по документации 1 3.1.2-возможность освоения ПС на контрольном примере 1 3.1.3-полнота и понятность документации для освоения 1 3.2 Простота использования 3.2.1-простота использования ИС 1 4.1. Временная эффективность 4.1.1-удовлетворение временем выполнения программ и выдачи ответа на 1. Функциональность ИС 2. Надёжность и безопасность ИС 2.1 Защищённость 2.2. Устойчивость функционирования 3. Удобство и практичность применения ИС 4. Эффективность 3.1. Простота освоения 64 0

запросы продолжение таблицы 3.1 1 2 4.2. Экономическая эффективность 5. Сопровождаемость 5.1. Внесение текущих изменений в ИС в процессе эксплуатации 3 4 4.1.2-удовлетворение временем подготовки входных данных 1 4.2.1-удовлетворение соотношением общих затрат на эксплуатацию ИС и получаемой прибылью 1 4.2.2-удовлетворение соотношением затрат на защиту данных и получаемой прибылью 0 5.1.1-наличие документов, которые содержат отведенные сроки внесения текущих изменений в ИС 1 Где k=13/20=0,7. Следовательно, ИС СД говорит о высокой оценке качества. При разработке показателей, оценивающих системы создания тестов, за основу были взяты особенности этого типа программ. В дальнейшем можно расширить перечень рассматриваемых показателей, изменить согласно особенностям других видов программных средств. Для определения оценки количественных признаков необходимо использование метрик качества. Измеренное значение отображено в масштабе на рисунке 3.2. Так как результат измерения оценки качества показал отличный результат, то установленный уровень имеет высокий приоритет. 65

1 Отличный 0,7 5 Установленный уровень Измеренные значения Удовлетворительно 0,5 Средний 0,25 Низкий Неудовлетворительно 0 Шкала метрики Рисунок 3.2 – Определение уровня оценки качества ИС СД Для определения качества ИС СД результаты оценивания характеристик должны иметь общий итог. Для этого были подготовлены процедуры, используемые, в таблице оценки качества ИС и средне взвешены. Процедура включает аспекты, такие как время и стоимость, которые способствуют оценке качества программной продукции в конкретных условиях эксплуатации. Перед разработкой любой ИС необходимо сначала разделить этапы разработки программы. В таблице 3.2 представлены этапы разработки ИС СД. Таблица 3.2 - Этапы разработки ИС СД Наименование этапа, работы Исполнитель 1 2 I. Разработка технического задания 1. Определение основных задач разработки ИС СД 66 АП

продолжение таблицы 3.2 1 2 2. Формирование списка задач и требований к разработке ИС СД РП, ОР 3. Составление технического задания ИС СД АП 4. Утверждение технического задания ИС СД РП, АП II. Изучение направления исследований 1. Обзор существующих аналоговых систем АП 2. Определение порядка реализации ИС СД ИП 4. Разработка план-графика ИП III. Теоретические и экспериментальные исследования 1. Разработка моделей и структур ИС СД ИП 2. Проведение программной реализации ИС СД ИП 3. Проведение тестирования ИС СД ИП, ОТ 4. Доработка недочетов и отладка ИС СД ИП 5. Исследование эффективности внедрения ИС СД АП IV. Обобщение и оценка результатов исследований 1. Написание технической документации АП 2. Составление и оформление отчёта АП 3.Тестирование ИС СД ОТ 4.Доработка недочетов ИП 5. Сдача программного продукта заказчику РП, АП Где: РП - руководитель проекта, ИП - инженер-программист, АП – аналитик проекта, ОТ – отдел тестирования. Также необходимо сделать расчет продолжительности этапов работ. Данный расчет представлен в таблице 3.3. 67

Таблица 3.3 - Расчёт продолжительности этапов и работ Наименование этапов и работ Исполнитель Кол-во исполнителей, чел. 1 2 3 Продолжительность, часов 4 I. Разработка технического задания 1. Определение основных задач разработки ИС СД АП 1 0,5 2. Формирование списка задач и требований к разработке ИС СД РП, АП 2 0,5 3. Составление технического задания ИС СД АП 1 2 4. Утверждение технического задания ИС СД РП, АП 3 1 Итого по этапу: продолжительность – 4 часа II. Изучение направления исследований 1. Обзор существующих аналоговых систем ИП 1 2 2. Определение порядка реализации ИС СД АП 1 1,5 3. Разработка план-графика ИП 1 1 Итого по этапу: продолжительность – 4,5 часов III. Теоретические и экспериментальные исследования 1. Разработка моделей и структур ИС СД ИП 1 2 2. Проведение программной реализации ИС СД ИП 1 70 ИП, ОТ 1 2 ИП 1 6 3. Проведение тестирования ИС СД 4. Доработка недочетов и отладка ИС СД 68

Ниже в таблице приведено измерение выполнения работ. Таблица 3.4 - Разработка технического задания Январь 2018 Трудоёмкость, Кол-во дни человек ИП 8 1 РП, ИП 6 2 Исполнитель 15 16 17 18 19 22 23 24 25 26 29 30 Итого по этапу: рабочих часов - 8; календарных дней – 12. Всего в работе по созданию автоматизированного рабочего места работника страховой компании приняло участие 4 человека. В том числе РП руководитель проекта, ИП - инженер-программист, АП – аналитик проекта, ОТ – отдел тестирования. Общая продолжительность разработки составляет 114 часов. Для этапа «Измерения» выделенные метрики были применены к программной продукции. В таблице 3.5 выделены подхарактеристики «Надежности», возможные меры и шкалы измерения. Надежность представляет собой свойства комплекса программ, которая обеспечивает наиболее низкую вероятность функционировании ПС в реальном времени. 69 отказа работы ИС, при

Таблица 3.5. - Подхарактеристики Надежности. Возможные меры и шкалы измерения количественных метрик Подхарактеристики и метрики Надежности Мера Шкала Секунды 85 Минуты 20 Минуты 40 Минуты 15 Вероятность 0,75 Завершенность  наработка на отказ при отсутствии перезагрузки. Отказоустойчивость  наработка на отказ при наличии автоматического перезапуска ИС СД;  ресурсы, обеспечивающие надежность и перезагрузку. Восстанавливаемость  период восстановления. Годность  время работоспособного функционирования. Эффективность представляет собой свойство ПС, которое обеспечивает необходимую производительность, ресурсов установленных в учитывая условиях. В количество таблице используемых 3.6 выделены подхарактеристики «Эффективности», возможные меры и шкалы измерения. 70

Таблица 3.6 - Подхарактеристики Эффективности. Возможные меры и шкалы измерения количественных метрик Подхарактеристики и метрики Эффективности Времяемкость  время отклика (подразумевает получение результатов на предоставленное задание);  пропускная способность (число предоставленных заданий, которые исполнялись на единицу времени). Используемость ресурсов  величина использования ресурсов компьютера в случае нормального функционировании ИС. Мера Шкала Секунды 3 Число в час 40 Вероятность 0,7 Практичность представляет собой свойство ПС, которое обуславливает сложность понимания ПС, а также изучения и использования, привлекательность для пользователей при применении в определенных условиях. В таблице 3.7 выделены подхарактеристики «Практичность», возможные меры и шкалы измерения. Таблица 3.7 - Подхарактеристики Практичности. Возможные меры и шкалы измерения основных метрик Подхарактеристики и метрики Практичности 1 Понятность   возможности ПС; наглядность и полнота документации. 71 Мера 2 Шкала 3 Порядковая Порядковая Хорошо Хорошо

Изучаемость    Человеко-часы Часы Страницы трудоемкость изучения ПС; продолжительность изучения ПС; объем документации. 1 10 120 80 2 3 Простота использования     простота управления функциями; комфортность эксплуатации; среднее время ввода заданий; среднее время отклика на задание. Привлекательность Порядковая Порядковая Секунды Секунды Хорошо Хорошо 5 40  субъективные или экспертные оценки. Порядковая Хорошо продолжение таблицы 3.7 Сопровождаемость представляет собой приспособленность ПС к различным модификациям, которые могут включать в себя адаптация ПС к изменениям внутренними в среде, усовершенствованиям. характеристиками подхарактеристики качества. «Сопровождаемость», Также В она таблице возможные определяется выделены 3.8 меры и шкалы измерения. Таблица 3.8. - Подхарактеристики Сопровождаемости. Возможные меры и шкалы измерения основных метрик Подхарактеристики и метрики Сопровождаемость 1 72 Мера Шкала 2 3

Анализируемость    стройность архитектуры программ; простота интерфейсов; полнота и корректность документации Порядковая Порядковая Порядковая Хорошо Удовлетворительно Хорошо Человеко-часы Часы 10 11 Изменяемость   трудоемкость подготовки измерений; длительность подготовки измерений 1 Стабильность 2 3  устойчивость к негативным проявлениям при изменениях. Порядковая Хорошо Человеко-часы 3 Часы 12 Тестируемость   трудоемкость тестирования изменений; длительность тестирования изменений продолжение таблицы 3.8 Таким образом, была разработана модель оценки качества программного продукта, с изначально установленными требованиями к ИС СД. Определены шаги оценки качества ИС СД, где были выделены: характеристики, промежуточные характеристики, детальные характеристики, подготовлены процедуры и средне взвешены. Выделены этапы разработки ИС, произведен расчет продолжительности этапов и работ, измерение выполнения работ, определены метрики оценивания и уровни ранжирования. 73

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

ЗАКЛЮЧЕНИЕ В результате выполнения выпускной квалификационной работы было выявлено, что задача разработки информационных средств оценки качества интерфейса программного продукта на основе UX-метрик является актуальной на сегодняшний день. Каждая компания стремится улучшить свое управление, повысить эффективность своей деятельности, а также быть лидирующей в своей отрасли среди конкурентов. Поэтому еще на начальном этапе разработки информационной системы являлось главным провести оценку качества программного продукта. Также были проанализированы существующие UXметрики, с помощью которых можно оценить качество взаимодействия программного продукта. Наиболее используемыми являются показатели, такие как: успешность выполнения заданий, время выполнения заданий, частотность проблем, субъективная удовлетворенность. Выявлен ряд недостатков данных метрик, к основным относятся:  отсутствие списков, снабженных характеристиками в зависимости от назначения проектируемой системы;  необходимость частого проведения пользовательских тестирований и результатов опросов требует тщательного отбора тестировщиков и дополнительных затрат;  отсутствие четкого описания оценки качества интерфейсов. На втором этапе выпускной квалификационной работы была проведена сравнительная оценка качества информационной системы страховой деятельности. Построена информационно-логическая модель ИС страховой деятельности. Разработана модель бизнес-процессов посредством методологии IDEF0, разработан алгоритм работы информационной системы страховой деятельности, разработана структура базы данных и интерфейс. При этом проанализированы и выбраны средства для проектирования и разработки информационной системы. Программный продукт ArisExpress использовался для построения структуры базы данных системы страховой деятельности, 75

состоящая из 12 таблиц: «БСО», «Вид страхования», «Договор страхования», «Документы об оплате», «Заявление», «Клиенты», «Клиенты/Страхование», «Пакет документов», «Предпринимательские риски», «Страхователь», «Страхование». Программный продукт Visio использовался для построения бизнес-процесса «Страхование», декомпозиции процесса «Страхование» и декомпозиция процесса «Оформление документов и печать». Также разработаны критерии работы информационной системы страховой деятельности в управлении предприятием. Была разработана методика с применением стандарта ISO 9126 к оценке качества программного продукта. Разработаны показатели оценки качества. Для определения оценки количественных признаков были использованы метрики качества, определен уровень качества программного продукта. Таким образом были разработаны информационные средства оценки качества интерфейса программного продукта на основе UX-метрик, спроектирована модель оценки качества программного продукта, с изначально установленными требованиями к информационной системе страховой деятельности, определены метрики оценивания и уровень качества системы. 76

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 1) Горбаченко ОБЕСПЕЧЕНИЯ И.М. ДЛЯ ОЦЕНКА СОЗДАНИЯ КАЧЕСТВА СИСТЕМ ПРОГРАММНОГО ТЕСТИРОВАНИЯ // Фундаментальные исследования. – 2013. – № 6-4. – С. 823-827. 2) ГОСТ Р ИСО/МЭК12119–2000.Информационная технология. Пакеты программ. Требования к качеству и тестирование. 3) ГОСТ Р ИСО/МЭК12207–99. Информационная технология. Процессы жизненного цикла программных средств. 4) ГОСТ Р ИСО/МЭК14764–2002.Информационная технология. Сопровождение программных средств. 5) ГОСТ Р ИСО/МЭК 15910–2002.Информационная технология. Процесс создания документации пользователя программного средства. 6) Википедия [Электронный ресурс] – Электрон. энциклопедия – Режим доступа URL: https://ru.wikipedia.org/wiki/%D3C, свободный. 7) Волошин, Г.Н. Обзор методологии IDEF0 [Электронный ресурс] / Г.Н. Волошин – Электр. текст. дан. Москва: 2005. – Режим доступа: http://idefinfo.ru/content/view/12/27/, свободный. 8) Бахтизин В.В., Глухова Л.А. Стандартизация и сертификация программного обеспечения: Учеб. пособие. – Мн.: БГУИР, 2006. 9) Липаев В.В. Обеспечение качества программных средств. Методы и стандарты. – М.: СИНТЕГ, 2001. 10) Обзор стандарта ISO 9126 [Электронный ресурс] / ISO 9126 (ГОСТ Р ИСО / МЭК 9126-93) – "Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению - Режим доступа: http://mediaknowledge.ru/fcc29aa7ecb359ec.html, свободный. 11) М.Кантор. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения - М., «Вильямс», 2002. 77

12) В.В.Липаев. Обеспечение качества программных средств - М., «Синтег», 2001. 13) Система страхового учета UNICUS 4.0 [Электронный ресурс] / Электрон. текст. дан – Режим доступа: http://www.systematic.ru/unicus.html, свободный 14) Carabi [Электронный ресурс] / Электрон. текст. дан – Режим доступа: https://carabi.ru/, свободный 15) PoeIS [Электронный ресурс] / Электрон. текст. дан – Режим доступа: https://studfiles.net/preview/2790182/page:4/, свободный 16) ИНЭК-Страховщик. История создания и краткое описание / ИНЭКСтраховщик. История создания и краткое описание – Режим доступа: http://sergeeva-i.narod.ru/inform/page561.htm, свободный 17) Создание информационной системы для организации / Анализ информационной системы. ИНЭК «Страховщик»– Режим доступа: http://www.studbooks.net/2175268/informatika/analiz_informatsionnoy_sistemy_ine k_strahovschik, свободный 18) Андон Ф.И., Суслов В.Ю., Коваль Г.И., Коротун Т.М. Основы качества программных систем.-Киев, Академпериодика.- 2002.-502с. 19) Милютин А., «Метрики кода программного обеспечения» [Электронный ресурс] - Режим доступа: http://www.viva64.com/ru/a/0045/, свободный. 20) Стадникова А.А. Процесс тестирования программного продукта как фактор повышения эффективности качества продукта[Текст]/А.А. Стадникова// Естественнонаучные, инженерные и экономические исследования в технике, промышленности, медицине и сельском хозяйстве: материалы I Молодѐжной научно-практической конференции с международным участием; под общ. ред. С.Н. Девицыной. – Белгород: ИД «Белгород» НИУ «БелГУ», 2017. − 693 с. 21) Стадникова А.А. Жизненные циклы строительных проектов и ИТпроектов [Текст]/А.А. Стадникова// Естественнонаучные, инженерные и экономические исследования в технике, промышленности, медицине и 78

сельском хозяйстве: материалы I Молодѐжной научно-практической конференции с международным участием; под общ. ред. С.Н. Девицыной. – Белгород: ИД «Белгород» НИУ «БелГУ», 2017. − 693 с. 22) Котляров, В. П. Основы тестирования программного обеспечения / В.П. Котляров, Т.В. Коликова. - М.: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2006. - 288 c. 23) Семерджян, М.А. Принципы работы и система программного обеспечения МП ЕС 2700 / М.А. Семерджян, Ж.С. Налбандян, Л.Х. Гаспарян. М.: Наука, 2004. - 244 c. 24) Кук, Ниалл Предприятие 2.0. Социальное программное обеспечение сегодня и завтра / Ниалл Кук. - М.: Аквамариновая Книга, 2010. - 224 c. 25) Дюваль Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска / Дюваль, М. Поль. - М.: Вильямс, 2008. - 240 c. 26) Абросимова, М.А. Информационные технологии в государственном и муниципальном управлении: Учебное пособие / М.А. Абросимова. - М.: КноРус, 2013. - 248 c. 27) Панов, А.В. Разработка управленческих решений: информационные технологии: Учебное пособие для вузов / А.В. Панов. - М.: Горячая линия Телеком , 2012. - 151 c. 28) Федулин, А.А. Информационные технологии / А.А. Федулин. - М.: КноРус, 2014. - 472 c. 29) Демистификация ИТ. Что на самом деле информационные технологии дают бизнесу. - М.: Альпина Паблишер, 2015. - 296 c. 30) Современные IT-решения для финансовой - Москва: Высшая школа, 2017. - 560 c. 31) Сенкевич, Г. Е. Информационная система малого предприятия "с нуля". Самое необходимое / Г.Е. Сенкевич. - М.: БХВ-Петербург, 2016. - 400 c. 79

32) Теличенко, В. И. Информационное моделирование технологий и бизнес-процессов / В.И. Теличенко, А.А. Лапидус, А.А. Морозенко. – М., 2016. - 144 c. 33) Информатика и ИКТ. Методическое пособие для учителей. Часть 2. Программное обеспечение информационных технологий / Под редакцией Н.В. Макаровой. - М.: Питер, 2008. - 432 c. 34) Алан Купер, Роберт Рейман, Дэвид Кронин. Алан Купер об интерфейсе. Основы проектирования взаимодействия. СПб, Символ-Плюс, 2009, 688 стр. 35) Стив Круг. Как сделать сайт удобным. Юзабилити по методу Стива Круга. СПб, Питер, 2010, 208 стр. 36) Дж. Гарретт. Веб-Дизайн: книга Джесса Гаррета. Элементы опыта взаимодействия. СПб, Символ-Плюс, 2008. 37) Расс Уингер, Кэролайн Чендлер. UX-дизайн. Практическое руководство по проектированию опыта взаимодействия. Символ-Плюс, 2011. 38) Волошин, Г.Н. Обзор методологии IDEF0 [Электронный ресурс] / Г.Н. Волошин – Электр. текст. дан. Москва: 2005. – Режим доступа :http://idefinfo.ru/content/view/12/27/, свободный. 39) Грекул, В.И. Проектирование информационных систем [Текст]: учеб. пособие / В.И. Грекул – ИНТУИТ, 2007. – 304с. 40) Ильин, В.В. Моделирование бизнес – процессов. Практическое моделирование [Текст] / В.В. Ильин. – М.:Вильямс, 2006. – 176 с. 41) Барановская, Т.М. Информационные системы и технологии [Текст] / Т.М. Барановская. – М.: Финансы и статистика, 2005 – 416 с. 42) Горошин, К.С. Обзор методологии ARISExpress [Электронный ресурс] / К.С.Горошин – Москва: 2010– Режим доступа: http://knowledge.allbest.ru/programming/2c0b65635a3bc78b4d53b88421206c36_0.h tml, свободный. 43) Информационные системы и технологии: Научное издание / Под ред. Ю.Ф. Тельнова. - М.: ЮНИТИ, 2012. - 303 c. 80

44) Диго С.М. Базы данных: проектирование и использование. Учебное пособие для вузов. – Москва.: Финансы и статистика, 2005. 45) Информационные системы и технологии управления: Учебник / Под ред. Г.А. Титоренко. - М.: ЮНИТИ, 2013. - 591 c. 46) Репин, В.В. Процессный подход к управлению. Моделирование бизнес – процессов [Текст] / В.В.Репин, В.Г. Елиферов. – М.:Оценка эффективности, 2008. – 408 с. 47) Питер, Р. Системы баз данных: проектирование, реализация и управление [Текст] / Р. Питер, К. Коронел. – Спб.: БХВ-Петербург, 2004. – 1040 с. 48) Лифиренко, М.В. Система поддержки принятия управленческих решений на основе усовершенствованного аналитико-иерархического процесса [Текст]/М.В. Лифиренко, «Белгородский В.В. Ломакин государственный – Белгород: национальный ФГАОУ ВПО исследовательский университет» – Рег. номер 2013616249 от 2.07.2013. 49) Функционально-ориентированные метрики [Электронный ресурс] / Н. Сапожников – Режим доступа: http://megapredmet.ru/1-35770.html, свободный. 50) Полковников, А.Н. Эффективное управление проектами [Электронный ресурс] / А.Н. Полковников - Режим доступа: http://sbiblio.com, свободный. 51) ИНТУИТ [Электронный ресурс] / Оценка информационных качества систем (ИС) – Режим доступа: https://www.intuit.ru/studies/courses/651/507/lecture/11551, свободный. 52) Оценка качества информационных систем [Электронный ресурс] / Электр. текст. дан. – Режим доступа: https://studfiles.net/preview/4646034/, свободный. 53) Информационные технологии [Электронный ресурс] / Оценка качества информационных систем 81 – Режим доступа:

https://studme.org/59750/informatika/otsenka_kachestva_informatsionnyh_sistem, свободный. 54) Алешин, Л.И. Информационные технологии: Учебное пособие / Л.И. Алешин. - М.: Маркет ДС, 2011. - 384 c. 55) Оценка качества информационной системы. Критерии качества ИС [Электронный ресурс] / Электр. текст. дан. – Режим доступа: http://mylektsii.ru/6-136315.html, свободный. 56) Развитие методов и средств взаимодействия пользователя с информационной системой на базе ГИС [Электронный ресурс] / Электр. текст. дан. – Режим доступа: https://cyberleninka.ru/article/, свободный. 57) Бородакий, Ю.В. Информационные технологии. Методы, процессы, системы / Ю.В. Бородакий, Ю.Г. Лободинский. - М.: ГЛТ , 2004. - 456 c. 58) Норенков, И.П. Автоматизированные информационные системы: Учебное пособие / И.П. Норенков. - М.: МГТУ им. Баумана, 2011. - 342 c. 59) Одинцов, Б.Е. Информационные системы управления эффективностью бизнеса: Учебник и практикум / Б.Е. Одинцов. - Люберцы: Юрайт, 2015. - 206 c. 60) Реутов, А.П. Автоматизированные информационные системы: методы построения и исследования / А.П. Реутов, М.В. Черняков, С.Н. Замуруев. - М.: Радиотехника, 2010. - 328 c. 61) Информационные системы и технологии: Научное издание. / Под ред. Ю.Ф. Тельнова. - М.: ЮНИТИ, 2016. - 303 c. 82

ПРИЛОЖЕНИЯ 83

ПРИЛОЖЕНИЕ А Структура оценивания продуктов ПС Формулирование целей оценивания Формирование требований к оцениванию Идентификация видов продуктов Спецификация модели качества Выбор метрик Спецификация оценивания Установка уровней ранжирования метрик Установка критерия оценивания Проектирование оценивания Разработка плана оценивания Измерение характеристик Выполнение оценивания Сравнение с критерием Оценка результатов 84 ISO 9126.1 Характеристики качества ISO 9126.2 Внешние метрики ISO 9126.3 Внутренние метрики ISO 14598.6 Модули оценивания

ПРИЛОЖЕНИЕ Б Схема данных в ARISExpress 85

ПРИЛОЖЕНИЕ В Декомпозиция процесса «Страхование» 86

ПРИЛОЖЕНИЕ Г Декомпозиция процесса «Оформление документов и печать» 87

ПРИЛОЖЕНИЕ Д Блок-схема алгоритма работы информационной системы страховой деятельности 88

Рецензии:

Авторизуйтесь, чтобы добавить рецензию

- у работы пока нет рецензий -

Отзывы:

Авторизуйтесь, чтобы оставить отзыв