Жизненный цикл информационных систем: от идеи до внедрения: учебное пособие 9785799637132

Table of contents :
Оглавление
От авторов
Введение
1. Этапы жизненного цикла информационной системы
1.1. Предпроектное обследование объекта внедрения и разработка требований к информационной системе
Основы применения системного подхода к решению проблем бизнеса средствами ИС
Методы системного анализа, ранжированные по этапам системного подхода
Классификация моделей
Постановка проблемы и целей ИТ-проекта
Возможные источники ограничений системы
Выявление заинтересованных лиц и пользователей ИС
Категории лиц, заинтересованных в новой информационной системе
1.2. Процесс разработки концепции информационной онлайн-системы
Описание объекта исследования
Постановка проблемы УНИИФ
Первоначальная постановка проблемы проекта
Предпроектное обследование УНИИФ
Моделирование уровня бизнес-стратегии полной модели архитектуры УНИИФ
Моделирование уровня бизнес-архитектуры
Матрица связей стратегических целей и бизнес-процессов УНИИФ
Моделирование уровня архитектуры приложений
Уровень ИТ-инфраструктуры
Фрагмент матрицы связей бизнес-процессов и приложений УНИИФ
Фрагмент матрицы связей приложений и специалистов УНИИФ
Анализ полной модели архитектуры УНИИФ
Дополнение уровня бизнес-архитектуры УНИИФ: моделирование AS-IS бизнес-процесса анализа данных
Разработка концепции ГИС «Очаги туберкулеза»
Выявление акторов, заинтересованных лиц и пользователей
Модель процесса анализа данных УНИИФ TO-BE
1.3. Проектирование информационной системы
Выбор модели жизненного цикла программного обеспечения для ИТ-проекта
Выбор модели жизненного цикла ИТ-проекта на основе характеристик требований к нему (критерии категории 1)
Выбор модели жизненного цикла ИТ-проекта на основе характеристик команды его разработчиков (критерии категории 2)
Выбор модели жизненного цикла ИТ-проекта на основе характеристик его пользователей (критерии категории 3)
Выбор модели жизненного цикла ИТ-проекта на основе характеристик его типов и рисков (критерии категории 4)
Общая модель информационной системы
Модель информационных потоков
Анализ осуществимости разработки информационной системы
1.4. Практический пример разработки функционального прототипа
2. Подход к разработке информационной системы
2.1. Разработка информационной системы
Классификация языков программирования
CASE-средства. Общая характеристика
2.2. Разработка информационных потоков для информационной системы
Разработка интерфейсной части
Обеспечение безопасности приложения
2.3. Тестирование программного обеспечения
Методика тестирования
Основные тесты
Нефункциональные тесты
2.4. Реализация функционального тестирования приложения
2.5. Ввод информационной системы в эксплуатацию в организации
Управление жизненным циклом корпоративной информации
Архитектура систем хранения данных
Сведения об информационной системе и ее жизненном цикле
Определение требований к системе
Полная модель жизненного цикла информационной системы для организации
Проектирование
3. Экономическое обоснование ИТ-проекта
3.1. Основные правила экономического обоснования ИТ-проекта
Пример жизненного цикла информационной системы в каскадной модели
3.2. Функции для экономического обоснования эффективности проекта
Понятие эффективности проекта
Подходы к оценке экономической эффективности проекта
Экономические методы оценки
Метод Total Cost of Ownership (TCO)
Метод Return of Investment (ROI)
Системные методы оценки
Метод Balanced Score Card (BSC)
Метод Performance Reference Model (PRM)
Метод Business Value of IT (BVIT)
Метод ITIL Service Strategy
Главные критерии оценки экономической эффективности проекта
3.3. Расчет экономического обоснования внедрения информационной системы
Стоимость одного часа работы на этапе инвестиций
Справочные величины по налогам и страховым взносам
Затраты на оплату труда на этапе инвестиций
Материальные вложения на этапе инвестиций
Нематериальные вложения на этапе инвестиций
Накладные расходы на этапе инвестиций
Стоимость одного часа работы на этапе эксплуатации
Затраты на оплату труда на этапе эксплуатации (ежемесячные)
Нематериальные вложения на этапе эксплуатации (ежемесячные)
Накладные расходы на этапе эксплуатации (ежемесячные)
Стоимость одного часа работы администратора информационной системы и инженера по информационной безопасности
Затраты на оплату труда специалистов, осуществляющих мониторинг системы безопасности AS-IS и TO-BE
Функционально-стоимостный анализ основных бизнес-процессов AS-IS и TO-BE
Сводная информация для расчета финансовых показателей
Оценка уровней защищенности информационной системы
Оценка уровней возможного ущерба организации
Стоимостная оценка рисков (модель AS-IS)
Стоимостная оценка рисков (модель ТО-ВЕ)
Ситуационные задачи
Задача 1
Исполнители
Алгоритм решения задачи
Задача 2. Экономическое обоснование ИТ-проекта
Исполнитель
Алгоритм решения задачи
Задача 3. Анализ осуществимости разработки информационной системы
Исполнители
Алгоритм решения задачи
Задача 4. Проектирование системы, разработка функционального прототипа
Исполнители
Алгоритм решения задачи
Задача 5. Разработка функционального прототипа системы/кодирование системы
Исполнитель
Алгоритм решения задачи
Пример таблицы для оценки языка программирования
Задача 6. Тестирование функционального прототипа
Исполнитель
Алгоритм решения задачи
Задача 7. Формирование технических требований
Исполнитель
Алгоритм решения задачи
Информационные ресурсы, рекомендуемые к изучению

Citation preview

---

А. А. ДЕТКОВ А. Ю. ВИШНЯКОВА А. А. ТАРАСЬЕВ

ЖИЗНЕННЫЙ ЦИКЛ ИНФОРМАЦИОННЫХ СИСТЕМ: ОТ ИДЕИ ДО ВНЕДРЕНИЯ Учебное пособие

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ УРАЛЬСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ ИМЕНИ ПЕРВОГО ПРЕЗИДЕНТА РОССИИ Б. Н. ЕЛЬЦИНА

А. А. Детков, А. Ю. Вишнякова, А. А. Тарасьев

ЖИЗНЕННЫЙ ЦИКЛ ИНФОРМАЦИОННЫХ СИСТЕМ: ОТ ИДЕИ ДО ВНЕДРЕНИЯ Учебное пособие Рекомендовано методическим советом Уральского федерального университета в качестве учебного пособия для студентов вуза, обучающихся по направлению подготовки 38.03.05, 38.04.05 «Бизнес-информатика»

Екатеринбург Издательство Уральского университета 2023

УДК 004.5(075.8) ББК 32.973.202я73-1 Д383

Р е ц е н з е н т ы: кафедра «Естественно-научные дисциплины» Уральского государственного университета путей сообщения (заведующий кафедрой доктор физико-математических наук, профессор Г. А. Тимофеева); Т. Ф. Филиппова, доктор физико-математических наук (Институт математики и механики УрО РАН)

Детков, А. А. Жизненный цикл информационных систем: от идеи до внедрения : учебД383 ное пособие / А. А. Детков, А. Ю. Вишнякова, А. А. Тарасьев ; Министерство науки и высшего образования Российской Федерации, Уральский федеральный университет. – Екатеринбург : Изд-во Урал. ун-та, 2023. – 158 с. : ил. – Библиогр.: с. 156. – 30 экз. – ISBN 978-5-7996-3713-2. – Текст : непосредственный. ISBN 978-5-7996-3713-2 В учебном пособии освещаются принципы построения этапов жизненного цикла информационных систем, сервисов и приложений, предназначенных для управления организациями и повышения их финансовой эффективности, а также приводятся ситуационные задачи, развивающие у будущих специалистов по бизнес-информатике компетенции в сфере предпроектного обследования, корректности постановки задач разработки и внедрения данных продуктов. Для студентов – будущих специалистов в области прикладного системного анализа, бизнесаналитики и разработки приложений.

УДК 004.5(075.8) ББК 32.973.202я73-1

ISBN 978-5-7996-3713-2

© Уральский федеральный университет, 2023

ОГЛАВЛЕНИЕ

От авторов ........................................................................................................... 4 Введение .............................................................................................................. 5 1. ЭТАПЫ ЖИЗНЕННОГО ЦИКЛА ИНФОРМАЦИОННОЙ СИСТЕМЫ .................... 7 1.1. Предпроектное обследование объекта внедрения и разработка требований к информационной системе ................................... 7 1.2. Процесс разработки концепции информационной онлайн-системы ............... 24 1.3. Проектирование информационной системы .................................................. 63 1.4. Практический пример разработки функционального прототипа ..................... 73 2. ПОДХОД К РАЗРАБОТКЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ............................ 87 2.1. Разработка информационной системы ......................................................... 87 2.2. Разработка информационных потоков для информационной системы ........... 90 2.3. Тестирование программного обеспечения .................................................... 98 2.4. Реализация функционального тестирования приложения ............................ 103 2.5. Ввод информационной системы в эксплуатацию в организации .................. 108 3. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ИТ-ПРОЕКТА ......................................... 125 3.1. Основные правила экономического обоснования ИТ-проекта ...................... 125 3.2. Функции для экономического обоснования эффективности проекта ............. 127 3.3. Расчет экономического обоснования внедрения информационной системы ... 135 Ситуационные задачи ........................................................................................... 149 Информационные ресурсы, рекомендуемые к изучению ........................................ 156

ОТ АВТОРОВ

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

ВВЕДЕНИЕ

Современное состояние рынка информационных технологий позволяет осуществить качественно новый переход к повышению уровня финансовой отдачи в реальном секторе экономики благодаря эффективным системам управления бизнес-процессами. В число ключевых условий успешной деятельности организации в настоящее время входят внедрение информационных систем в бизнесе, проведение предпроектного обследования и применение методов системного анализа как к секторам рынка, так и к системам организаций. При этом требуется комплексное решение вопроса повышения эффективности бизнес-структур посредством минимизации издержек, повышения производительности труда и уровня подготовки кадров в области экономики, управления и развития информационных технологий, что позволит обеспечить переход к цифровой экономике. В связи с этим повышается актуальность подготовки специалистов в области постановки задач проектирования, разработки и внедрения информационных систем управления организацией, владеющих навыками анализа рыночной ситуации и включения цифровых продуктов в бизнес-системы. Информационная система – это комплекс инструментальных средств, сервисов, методов, «информационных потоков», необходимых для реализации деятельности организации. Период времени от момента принятия решения о создании информационной системы вплоть до ее полного изъятия из эксплуатации называется жизненным циклом ИС. ГОСТ Р 57193-2016 «Системная и программная инженерия. Процессы жизненного цикла систем», основанный на международном стандарте, вводит следующее определение жизненного цикла: это «развитие проекта системы, продукции, услуги или другой создаваемой человеком сущности от замысла до списания»1. В ГОСТ Р 50-605-80-93 «Система разработки и постановки продукции на производство. Термины и определения» уточняется, что «жизненный цикл – это не временной период существования, а процесс последовательного изменения состояния, обусловленный видом производимых воз1 ГОСТ Р 57193-2016. Системная и программная инженерия. Процессы жизненного цикла систем // Все ГОСТы : сайт. URL: http://vsegost.com/Catalog/63/63089.shtml (дата обращения: 01.03.2023).

5

действий»2. Жизненный цикл продукта подразделяется на пять стадий: разработка, внедрение, рост, зрелость и спад. Согласно стандарту IEEE standard glossary of software engineering terminology (IEEE Std 610.12-1990) жизненный цикл информационной системы – это «период времени, который начинается, когда проектируется информационная система, и заканчивается, когда информационная система становится непригодна для использования»3 (здесь и далее перевод наш. – Авт.). Обычно жизненный цикл информационной системы включает следующие этапы: разработка концепции; выявление требований; проектирование ИС; ее разработка; тестирование; установка, проверка и ввод в эксплуатацию; эксплуатация и обслуживание, а иногда – этап вывода из эксплуатации. Эти этапы могут реализовываться как параллельно, так и итеративно. Жизненный цикл разработки информационной системы в стандарте IEEE Std 610.12-1990 определяется как «период времени, который начинается с принятия решения о разработке и заканчивается, когда программное обеспечение поставляется»4. Обычно разработка информационной системы включает следующие этапы: выявление требований; проектирование; реализация; тестирование; а иногда – этап установки и проверки. Перечисленные этапы также могут перекрываться или выполняться итеративно в зависимости от подхода, используемого при разработке программного обеспечения. Из данных в стандарте IEEE Std 610.12-1990 определений следует, что жизненный цикл информационной системы включает в себя жизненный цикл ее разработки.

2 ГОСТ Р 50-605-80-93. Система разработки и постановки продукции на производство. Термины и определения // OpenGost.ru : сайт. URL: https://www.opengost.ru/iso/01_gosty/ 01110_gost_iso/1991-r-50-605-80-93-sistema-razrabotki-i-postanovki-produkcii-na-proizvodstvo.terminy-i-opredeleniya.html (дата обращения: 01.03.2023). 3 IEEE standard glossary of software engineering terminology (IEEE Std 610.12-1990) : site. URL: http://www.informatik.htw-dres-den.de/~hauptman/SEI/IEEE_Standard_Glossary_of_ Software_Engineering_Terminology%20.pdf (date of request: 01.03.2023). 4 Ibid.

6

1. ЭТАПЫ ЖИЗНЕННОГО ЦИКЛА ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

Если программный продукт предназначен для массового распространения, то организация-разработчик должна обеспечить как универсальность функций обработки данных, так и настраиваемость программного продукта согласно конкретным условиям его применения. Специфика программных продуктов заключается в их системности – полноте и завершенности совокупно реализуемых функций обработки данных. Согласно стандарту IEEE Std 610.12-1990 жизненный цикл программного продукта – это период времени, который начинается, когда программный продукт только задумывается, и заканчивается, когда он больше не доступен для использования. Обычно жизненный цикл программного продукта включает следующие этапы: разработка концепции; выявление требований; проектирование; реализация; тестирование; установка и проверка; эксплуатация и обслуживание и (иногда) – этап вывода из эксплуатации. Эти этапы могут выполняться и параллельно, и итеративно. Информационная система – это среда, элементами которой являются компьютеры, компьютерные сети, программные продукты, базы данных, люди, различного рода технические и программные средства связи и т. д., а основная цель заключается в организации хранения и передачи информации. Иными словами, ИС представляет собой человеко-компьютерную систему обработки информации. Соответственно понятие информационной системы включает в себя понятие программного продукта с учетом всех составляющих его систем, сервисов и приложений, концептуально обеспечивающих функционирование бизнес-процессов организации путем комплексной интеграции в рамках реализации концепции управления эффективностью бизнеса (Business Performance Management). При разработке информационных систем для бизнеса целесообразно использовать системный подход (это универсальный подход к решению любых проблем). В рамках этого подхода бизнес-аналитик сначала рассматривает интересующий его объект – бизнес-систему как систему, состоящую из ряда элементов – бизнес-процессов, а затем – как элемент некоторой большей системы – архитектуры бизнеса (чаще используется понятие «архитектура предприятия» – Enterprise Architecture). В самом общем виде под архитектурой предприятия понимается всестороннее и исчерпывающее описание (модель) всех его ключевых элементов и межэлементных отношений, которые традиционно представляются в виде указанных ниже уровней: – уровень бизнес-стратегии (отображает основные цели и задачи предприятия (организации); – уровень бизнес-процессов (отображает структуру бизнес-процессов и организационную структуру); 8

– уровень приложений (отображает системы, хранилища, приложения и сервисы, их связь друг с другом и с бизнес-процессами); – уровень ИТ-инфраструктуры (отображает программно-аппаратные средства, обеспечивающие поддержку уровня приложений). Между уровнями описания комплексной структуры предприятия (организации) и выявления слабых звеньев в системе его управления и развития существует иерархия. Высший уровень (уровень бизнес-стратегии) формируется на ранних этапах становления бизнеса, определяющих его идею и миссию. Далее идет формирование уровня бизнес-процессов, направленных на достижение стратегических целей бизнеса. Для автоматизации бизнеспроцессов закупаются различные программные продукты, и тем самым формируется третий уровень, уровень приложений. Для функционирования уровня приложений необходима соответствующая ИТ-инфраструктура; ее описание – это низший уровень архитектуры предприятия (организации), уровень ИТ-инфраструктуры. Анализируя модели бизнес-процессов и включающую их модель архитектуры предприятия (организации) и определенным образом осмысливая получаемые данные, бизнес-аналитик выявляет имеющиеся проблемы. Далее он предлагает способы решения этих проблем, оценивает их и выбирает лучшие с учетом внутренних и внешних ограничений, накладываемых и самим бизнесом (недостаточные ресурсы и возможности), и внешней средой (давление, оказываемое конкурентами или правительственными организациями). Проблема – это условие, которое может причинить (или уже причиняет) бизнесу определенный ущерб. В процессе преодоления каждой проблемы менеджерам приходится принимать многочисленные решения. Под принятием решения понимают акт выбора стратегии, которая, по мнению бизнесаналитика, приведет к устранению проблемы. При использовании системного подхода к решению проблемы на каждом из его этапов применяются различные инструменты и методы системного анализа5. При этом сам системный подход выполняет роль так называемого методологического каркаса, объединяющего все необходимые методы, исследовательские приемы, мероприятия и ресурсы для решения обнаруженных проблем. Метод (от греч. methodos – путь, способ исследования, обучения, изложения) – это совокупность приемов и операций познания и практической деятельности; способ достижения определенных результатов в познании 5

Об истории возникновения системного подхода к решению проблемы, его этапах и особенностях см.: Вишнякова А. Ю., Берг Д. Б. Прикладной системный анализ в сфере ИТ: предварительное проектирование и разработка документ-концепции информационной системы : учебное пособие. Екатеринбург : Изд-во Урал. ун-та, 2020. 179 с. 9

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

Этап системного подхода

Задачи этапа

Методы

1

Работа с проблемой

Обнаружение проблемы. Формулировка проблемы. Определение актуальности проблемы. Анализ развития проблемы в прошлом и будущем. Анализ разрешимости проблемы

Метод сценариев. Диагностический метод. Деревья целей. Методы экономического анализа. Построение кибернетических моделей

2

Работа с целями

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

Метод экспертных оценок («Делфи»). Деревья целей. Методы экономического анализа. Морфологический метод. Построение кибернетических моделей. Построение нормативных операционных моделей (оптимизационных, игровых, имитационных)

3

Работа с системой

Определение субъекта наблюдения («наблюдателя»), формирующего систему.

Сетевые методы. Морфологические методы. Диагностические методы.

10

Продолжение № п/п

Этап системного подхода

Задачи этапа

т а б л. 1

Методы

Определение системы. Анализ системы, построение моделей (выделение элементов, подсистем, определение среды, структуры). Выявление недостатков. Формирование требований

Матричные методы. Методы сценариев. Методы мозгового штурма. Построение кибернетических моделей

4

Работа с альтернативами

Разработка максимального количества возможностей (альтернатив) достижения целей. Оценка и сравнение вариантов. Выбор наилучших вариантов. Формирование комплекса взаимосвязанных вариантов

Деревья целей. Матричные методы. Методы экономического анализа. Морфологический метод

5

Работа над решением

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

Матричные методы. Сетевые методы. Методы экономического анализа. Метод экспертных оценок («Делфи»). Деревья целей. Построение описательных моделей. Построение нормативных операционных моделей (оптимизационных, игровых, имитационных)

6

Осуществление решения

Моделирование решения. Испытание моделей. Оценка и выбор моделей. Оптимизация моделей

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

11

Окончание № п/п

7

Этап системного подхода

Внедрение решения

т а б л. 1

Задачи этапа

Методы

Подготовка к внедрению. Внедрение решения и контроль процесса внедрения. Оценка эффективности реализации и последствий

Методы экономического анализа. Морфологические методы. Статистические методы

Не сложно заметить, что особое место в системе методов занимает моделирование – метод познания, который заключается в представлении предметов, систем, процессов и явлений в виде идеальных абстрактных образов – моделей и их исследовании. Таким образом, результатом моделирования является модель – материальный или идеальный объект, замещающий исследуемую систему и адекватным образом отображающий ее существенные стороны. Модель объекта (процесса, явления) отражает его свойства и связи между ними. Чем больше свойств и связей воплощено в модели, тем ближе модель к реальному объекту. Учитываемые в модели свойства объекта (из огромного их числа) называются признаками, или характеристиками. Среди отражаемых в модели признаков различают переменные и параметры. Переменные – это признаки, которые могут иметь разные значения и не влияют на характер модели. Признаки, оказывающие наиболее существенное влияние на поведение моделируемого объекта, называются факторами. Качественная либо количественная характеристика переменных осуществляется через показатели. Взаимосвязь между переменными отражается через параметры – относительно постоянные характеристики модели, изменение которых ведет к изменению ее характера. Существующие модели чрезвычайно разнообразны, и применяются различные способы их классификации (табл. 2). Основными этапами моделирования являются: 1) постановка задачи, включающая: – ее описание; – определение цели моделирования; 2) разработка модели, анализ и исследование задачи, включающие: – выбор способа и инструмента моделирования; – построение информационной модели, то есть формирование представления об элементах, составляющих исходный объект моделирования (анализ объекта моделирования); 3) компьютерный (натурный, физический) эксперимент; 4) анализ результатов моделирования. 12

Таблица 2 Классификация моделей

По отношению ко времени

По характеру моделируемой стороны объекта

Способ классификации

Характеристика

Тип моделей

Кибернетические (функциональные) модели

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

Структурные модели

Структура этих моделей соответствует структуре моделируемого объекта. Примеры. Командно-штабные учения, день самоуправления и т. д.

Информационные модели

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

Статические модели

Это модели, состояние которых не изменяется с течением времени. Примеры. Макет застройки квартала, модель кузова машины и т. д.

Динамические модели

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

Продолжение

По способу реализации

По степени случайности моделируемого процесса

По способу представления состояния системы

Способ классификации

Тип моделей

т а б л. 2

Характеристика

Дискретные модели

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

Непрерывные модели

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

Дискретнонепрерывные модели

Представляют собой комбинацию дискретной и непрерывной моделей

Детерминированные модели

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

Стохастические модели

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

Абстрактные (нематериальные) модели

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

Материальные (физические, реальные) модели

Эти модели представляют собой неподвижные макеты либо действующие устройства, функционирующие в чем-то подобно исследуемому объекту. 14

Окончание Способ классификации

Тип моделей

т а б л. 2

Характеристика

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

В случае выявления необходимости построения математических моделей для решения проблемы бизнеса моделирование усложняется включением дополнительных блоков. Блок 1. Обследование объекта моделирования (бизнеса, бизнес-процесса, информационной системы и т. д. в зависимости от этапа решения проблемы и ее особенностей) и формулировка задания на разработку модели. Назначение этого блока – разработка содержательной постановки задачи моделирования, то есть создание совокупности вопросов об объекте моделирования, записанных в словесной форме. Блок 2. Концептуальная и математическая постановка задачи. Цель концептуальной постановки задачи заключается в формулировке основных вопросов и гипотез касательно свойств и поведения объекта моделирования. В итоге набор предположений описывается математически для количественного анализа их выполнения. Математическая постановка задачи моделирования – процесс получения совокупности математических уравнений. Блок 3. Качественный анализ и проверка корректности модели. Математическая модель является корректной, если результат всех ее контрольных проверок – положительный. Контрольные проверки включают: – контроль размерности; – контроль порядков; – контроль характера зависимостей; – контроль экстремальных ситуаций; – контроль граничных условий; – контроль физического смысла; – контроль математической замкнутости. Блок 4. Выбор метода решения задачи и его обоснование. Требуется найти наиболее эффективный (по быстроте получения решения и его наибольшей точности) метод решения для последующей его реализации в форме алгоритма. 15

Блок 5. Реализация алгоритма метода решения задачи в виде программ для ЭВМ. Осуществляется данная деятельность с использованием современных программных продуктов. Успешность создания требующегося продукта зависит от знания современных алгоритмических языков, технологий и языков кодирования и ресурса вычислительных систем. Блок 6. Проверка адекватности математической модели реальному процессу (для этого результаты измерений на действующем объекте нужно сравнить с результатами предсказания модели в идентичных условиях). Блок 7. Практическое использование модели. Независимо от области применения созданной модели необходимо провести качественный и количественный анализ результатов моделирования, который позволяет: – выполнить модификацию рассматриваемого объекта, найти его оптимальные характеристики; – обозначить область применения модели; – проверить обоснованность гипотез, принятых на этапе математической постановки задачи моделирования, оценить возможность упрощения модели с целью повышения ее эффективности при сохранении требуемой точности; – показать, в каком направлении следует развивать модель в дальнейшем. Более подробно особенности математического моделирования на этапе принятия решений в рамках системного подхода рассматриваются в работе «Системы поддержки принятия управленческих решений»6. При построении моделей используют два подхода: – дедуктивный (от общего к частному); – индуктивный (от частного к общему). При дедуктивном подходе при заданных предположениях фундаментальная модель приспосабливается к условиям моделируемого объекта. Индуктивный метод предполагает выдвижение гипотез, декомпозицию сложного объекта, анализ, а затем – синтез. Основными требованиями, предъявляемыми к моделям, выступают требования универсальности, точности, адекватности и экономичности. Универсальность модели характеризует полноту отображения в ней свойств реального объекта. В модели обычно воплощаются лишь некоторые свойства объекта (например, протекающие в нем физические или информационные процессы), без учета геометрической формы составляющих объект элементов или наоборот. 6 См.: Системы поддержки принятия управленческих решений / М. А. Медведева, А. О. Коломыцева, А. Ю. Вишнякова, Е. А. Искра. Екатеринбург : Изд-во Урал. ун-та, 2019. 202 с.

16

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

Постановка проблемы и целей ИТ-проекта Любой проект по разработке и / или внедрению новой информационной системы начинается в первую очередь с того, что заказчик осознает наличие в его бизнесе какой-либо проблемы, которую можно решить ИТ-средствами. Далее это осознание перерастает в первоначальную постановку проблемы, которая должна быть доведена до сведения всех заинтересованных лиц (руководства, ИТ-специалистов, работников, непосредственно связанных с рассматриваемой проблемой). Данный шаг имеет первостепенное значение, так как он позволяет избежать пустой траты огромных усилий, прилагаемых к решению несуществующей или несущественной проблемы бизнеса (что на практике наблюдается нередко). Один из простейших способов представления обнаруженной проблемы заключается в следующем: нужно записать в стандартной форме ее формулировку и выяснить, все ли заинтересованные лица с ней согласны (рис. 1).

Проблема

Воздействует на…

Описание проблемы

Указать, на кого и на что оказывает влияние данная проблема

Результатом чего является...

Описание воздействия данной проблемы на заинтересованных лиц и бизнесдеятельность

Выигрыш от…

Приводится предлагаемое решение

...может состоять в следующем...

Список основных предоставляемых решением преимуществ

Рис. 1. Стандартная форма первоначальной постановки проблемы 17

Не учтенное на данном этапе мнение хотя бы одного из заинтересованных лиц может полностью переориентировать и формулировку проблемы, и направление поиска ее решения. В случае достижения соглашения между всеми заинтересованными лицами о необходимости решения данной проблемы последняя должна быть системно изучена для конкретизации, уточнения (поскольку первоначальная постановка проблемы в процессе ее обсуждения может быть изменена) и постановки целей по ее преодолению (решение «в лоб», особенно сложных, плохо изученных проблем, причины и следствия которых не очевидны, может привести к ошибочной постановке целей и к результатам, которые или не до конца снимают проблемную ситуацию, или совсем не удовлетворяют реальным требованиям бизнеса). Определить цель проекта – значит ответить на вопрос, что надо сделать для снятия проблемы. Сформулировать цель – значит указать направление, в котором следует двигаться, чтобы разрешить обнаруженную проблему, и пути, которые позволяют это сделать. Любые информационные системы разрабатываются и реализуются на основе заявленных к ним требований. Требования к информационной системе – это описание функциональных возможностей ИС и ограничений, накладываемых на нее. Требования нужны для того, чтобы разработчик (исполнитель ИТ-проекта) ´ и финансовые персмог определить и согласовать с заказчиком временные пективы проекта. Соответственно, значительная часть требований должна быть собрана и обработана на ранних этапах создания информационной системы. Однако собрать на ранних этапах все данные, необходимые для реализации ИС, удается только в исключительных случаях. На практике процесс сбора, анализа и обработки требований заказчика растянут во времени на протяжении всего жизненного цикла ИС, зачастую нетривиален и содержит множество «подводных камней». Бизнес-требования (business requirements) – это требования, которые позволяют понять, почему бизнесу нужна выбранная информационная система, то есть понять цели, которые необходимо достичь с ее помощью. Как правило, данные требования высказывают те, кто финансирует проект, покупатели информационной системы, менеджер реальных пользователей, отдел маркетинга или ответственный за концепцию продукта. Таким образом, бизнес-требование на первых этапах решения проблемы формулирует заказчик, и его формулировка совпадает с целью проекта по преодолению рассматриваемой проблемы, но дополнительно конкретизируется заявленными критериями к итоговому результату. Исходя из полученной формулировки цели и задач проекта необходимо задать критерии и ограничения, при которых будет осуществляться их достижение (табл. 3). 18

Таблица 3 Возможные источники ограничений системы № п/п

Источник

Ограничение (возможные вопросы)

1

Экономический

Какие финансовые или бюджетные ограничения следует учесть? Существуют ли соображения, касающиеся себестоимости и ценообразования? Существуют ли вопросы лицензирования?

2

Политический

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

3

Технический

Существуют ли ограничения в выборе технологий? Должны ли мы работать в рамках существующих платформ или технологий? Запрещено ли использование любых новых технологий? Должны ли мы использовать какие-либо закупаемые пакеты программного обеспечения?

4

Системный

Будет ли решение создаваться для наших существующих систем? Должны ли мы обеспечивать совместимость с существующими решениями? Какие операционные системы и среды должны поддерживаться?

5

Эксплуатационный

Существуют ли ограничения информационной среды или правовые ограничения? Юридические ограничения? Требования безопасности? Какими другими стандартами мы ограничены?

6

График и ресурсы

Определен ли график? Ограничены ли мы существующими ресурсами? Можем ли мы привлекать работников со стороны? Можем ли мы увеличить штат? Временно? Постоянно?

Критерий (от греч. kriterion – средство для суждения) – это признак, на основании которого производятся оценка, определение или классификация чего-либо; мерило, оценка. В качестве критерия достижения целей часто выбирают показатель эффективности системы, который может выражаться как в качественной, так и в количественной форме. При разработке показателей эффективности системы необходимо придерживаться указанных ниже правил. 1. Каждый показатель должен быть измерим. 19

2. Набор показателей должен содержать минимально необходимое их количество для обеспечения полноценного управления бизнес-процессом. 3. Стоимость измерения показателя не должна превышать экономический эффект от использования данного показателя. Наряду с заданными критериями большое влияние на выбор того или иного варианта решения оказывает система выделенных ограничений – условий, отражающих влияние внешних и внутренних факторов, которые нужно учитывать при принятии решений. При этом необходимо сообразовываться с тем, что спектр источников ограничений весьма разнообразен: это источники организационные; экономические; правовые; технические; экологические; эксплуатационные; психологические и т. д. Качественные ограничения формулируются, как правило, императивно («не разрешается», «не допускается»), а количественные имеют менее жесткие рамки («не более», «не менее», «в интервале от – до»). Ограничения обычно дополняют (конкретизируют) сформулированные ранее цели и в ряде случаев могут сделать эти цели нереализуемыми. При формировании целей, критериев и ограничений используется так называемое пространство целеполагания – совокупность систем, предъявляющих требования к исследуемой системе. В пространство целеполагания также включается сама система, предъявляющая собственные требования. После завершения исследования проблемы, формулировки цели и задач проекта проводится анализ (предпроектное обследование) и бизнеса в целом, и, в частности, его подсистемы, в которой выявлена рассматриваемая проблема (это может быть структурное подразделение или конкретный бизнеспроцесс). Выбор объекта для анализа зависит от решаемой проблемы и поставленных задач. На данном этапе рассматриваются: – цели и задачи исследуемой системы / подсистемы; – границы системы / подсистемы; – состав и структура системы / подсистемы; – выполняемые функции системы / подсистемы. Таким образом, предпроектное обследование – это комплекс мер, направленных на изучение структуры бизнеса, его бизнес-процессов, взаимодействия отделов и структурных подразделений организации между собой, а также на изучение уже имеющегося программного обеспечения (ПО), эффективности его работы и возможности для потенциальной интеграции с новой информационной системой и расширения функционала. В предпроектном обследовании обязательно участие двух сторон: заказчика и исполнителя системного проекта (если исполнителем будет внешнее лицо). При этом роль заказчика не ограничивается финансированием работы: от него требуется анализ подсистемы, которой он управляет, определение цели и возможных вариантов действий. 20

Результатом предпроектного обследования бизнеса является разработка полной модели его архитектуры, а результатом анализа конкретной подсистемы могут стать или архитектура конкретного структурного подразделения (включая модели исполняемых бизнес-процессов), или только модели бизнеспроцессов AS-IS, содержащих проблему. Вся информация о документировании и моделировании бизнес-процессов должна пройти этап рецензирования или верификации. На этом этапе при поддержке консультантов и проектной группы проинтервьюированные сотрудники проверяют модели процессов, что гарантированно обеспечивает качество документированных моделей. После построения и проверки перечисленных моделей проводится их экспертный анализ, направленный: – на выявление слабых мест в деятельности организации и определение необходимости тех или иных изменений в ее структуре; – обеспечение поддержки бесперебойного исполнения действующих эффективных бизнес-процессов. По итогам работы формируется документ с результатами анализа, после чего рассматриваются варианты решения выявленных проблем, проводятся анализ альтернатив и оценка рисков, по результатам которых выбирается наилучшее решение. Укажем основные требования, предъявляемые к оценке эффективных решений. 1. Решение должно быть обоснованным, то есть при его выборе должно учитываться влияние всех положенных в его основу критериев. 2. Решение должно быть реальным, то есть таким, чтобы его можно было претворить в жизнь. Соблюсти данное требование позволяет последовательное разбиение сложных решений на решения простые. 3. Решение должно быть своевременным, то есть приниматься в тот момент, когда его исполнение особенно целесообразно. 4. Решение должно быть гибким, что предполагает изменение алгоритма его принятия при изменении внутренних и внешних условий. 5. Решение должно приносить максимальную выгоду. Выгодой может стать либо получаемая по результатам решения прибыль, либо сокращение времени на проведение работ, либо исполнение принятых норм и стандартов. Выявленное наилучшее решение также требует определения ограничений и допущений на свою реализацию, а также учета требований заинтересованных лиц.

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

зрения) и поэтому должна участвовать в формировании требований к ИС. Эти взгляды, точки зрения и требования могут пересекаться, а могут и не пересекаться, но главное то, что они позволяют рассматривать проблему с разных сторон и учитывать запросы всех заинтересованных лиц. Заинтересованные лица – это все те, на кого реализация новой информационной системы может оказать воздействие. Понимание потребностей пользователей и других заинтересованных лиц является в разработке успешного решения ключевым фактором. Выделяют несколько категорий заинтересованных лиц, они представлены в табл. 4. Таблица 4 Категории лиц, заинтересованных в новой информационной системе № п/п

Категория

Описание

1

Пользователи системы

Лица (группы лиц, организации), пользующиеся услугами информационной системы для получения информации или решения других задач (ГОСТ 7.0 99)

2

Непрямые пользователи

Лица (группы лиц, организации), косвенно пользующиеся результатами работы ИС

3

Потребители системы

Лица (группы лиц, организации), на которых воздействуют бизнес-последствия реализации ИС

4

Стейкхолдеры

Лица (группы лиц, организации), которые вовлечены в реализацию ИС или воздействуют на нее

Каждая из перечисленных категорий заинтересованных лиц может оказывать влияние на требования к информационной системе или быть в дальнейшем каким-либо образом связанной с результатом ее работы. Соответственно потребности заинтересованных лиц, не относящихся к категории пользователей, тоже необходимо выявить и учесть. Для этого зачастую вполне достаточно опросить тех, кто принимает решения, а также потенциальных пользователей и другие заинтересованные стороны. В этом процессе могут оказаться полезными приведенные ниже вопросы. 1. Кто является пользователем системы? 2. Кто является заказчиком (экономическим покупателем) системы? 3. На кого еще окажут влияние результаты работы системы? 4. Кто будет оценивать и принимать систему, когда ее представят и развернут? 5. Кто будет заниматься сопровождением системы? 22

6. Существуют ли другие внутренние или внешние пользователи системы, чьи потребности необходимо учесть? 7. Не забыли ли мы кого-нибудь? После определения пользователей информационной системы и заинтересованных в ней лиц необходимо собрать и задокументировать их требования. Требования пользователей (user requirements) описывают цели или задачи, которые должны выполняться с помощью информационной системы. Для выделения первоначальных требований пользователей могут применяться такие методы, как мозговой штурм; анкетирование; интервью; автозапись; этнографический метод и т. д. К самым простым и малозатратным методам относятся в данном случае анкетирование и интервью, но результаты, полученные с их помощью, зачастую бывают плохо структурированными, дублирующимися, противоречивыми, неполными, что требует дополнительной их корректировки на дальнейших этапах проекта. Универсального подхода к выявлению и анализу требований к информационной системе не существует, поэтому одновременно следует использовать сразу несколько методов. Далее для доработки первоначальных требований к информационной системе рекомендуется провести выявление и идентификацию ключевых узлов взаимодействия ИС и сторонних ей элементов (акторов). Актор – это находящийся вне информационной системы элемент (сервис, участник), с ней взаимодействующий. Акторы осуществляют комплекс воздействий, заставляя систему функционировать. Выявление акторов – это ключевой аналитический этап в разработке требований к информационной системе. Обнаружить акторов и ключевые узлы взаимодействия их с ИС помогут ответы на приведенные ниже вопросы. 1. Кто будет поставлять, использовать или удалять информацию из системы? 2. Кто будет управлять системой? 3. Кто будет осуществлять сопровождение системы? 4. Где будет использоваться система? 5. Откуда система получает информацию? 6. Какие внешние системы будут взаимодействовать с данной системой? Для идентификации ключевых узлов взаимодействия акторов с информационной системой широко используется метод мозгового штурма: организуется встреча заинтересованных в системе лиц, на которой выясняются предъявляемые ими требования. Далее определяются и записываются системные сервисы, то есть те функции, которые акторы ждут от системы. При этом один и тот же сервис может быть соотнесен с несколькими узлами взаимодействия системы с акторами. Узлы взаимодействия в информационной системе также определяют входные и управляющие данные для ее сервисов. 23

Входные данные – это данные, введенные в систему для их сохранения или обработки (например, логин, пароль, ФИО и т. д.). Управляющие данные – это данные, которые используются для управления программой (например, выбор сервиса, отмена операции и т. д.).

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

Описание объекта исследования Организацией, на основе статистических данных которой реализована ГИС «Очаги туберкулеза», выступил Уральский научно-исследовательский институт фтизиопульмонологии – филиал ФГБУ «НМИЦ ФПИ» Минздрава России (УНИИФ) как одно из основных медицинских учреждений, специализирующихся на лечении тяжелых легочных заболеваний. В настоящее время УНИИФ является региональным центром высокотехнологичной медицинской помощи, организационно-методическим, обучающим и научноклиническим центром по вопросам организации противотуберкулезных мероприятий в субъектах РФ: Приволжском федеральном округе (ПФО) и Уральском федеральном округе (УрФО). УНИИФ предоставляет полный спектр услуг по профилактике, обследованию и лечению профильных заболеваний. Высокотехнологичная консультативная и стационарная лечебно-диагностическая помощь оказывается в клинике УНИИФ по дифференциальной диагностике туберкулеза всех локализаций с использованием инструментально-биоптических методов диагностики; по лечению легочного туберкулеза, в том числе с множественной лекарственной устойчивостью; по хирургии легочного туберкулеза и туберкулеза внелегочных локализаций (урогенитального, туберкулеза позвоночника, костей и суставов).

Постановка проблемы УНИИФ В 2018 году, несмотря на снижение общего уровня заболеваемости туберкулезом в некоторых субъектах РФ, наблюдался рост лекарственной устойчивости микробактерии туберкулеза, что делало стандартные методы химиотерапии все менее эффективными. Новых противотуберкулезных лекарст24

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

Описание

1. Проблема

Снижение эффективности стандартных мер по борьбе с туберкулезом

2. Воздействует на…

На население РФ

3. Результатом чего является…

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

4. Выигрыш от…

От реализации геоинформационной системы

5. Может состоять в…

В повышении качества мер реагирования и борьбы с туберкулезом

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

Предпроектное обследование УНИИФ Моделирование уровня бизнес-стратегии полной модели архитектуры УНИИФ Миссией УНИИФ является развитие биомедицины, прогностических и профилактических подходов к лечению пациентов, подходов, позволяющих раскрыть потенциальные и адаптационные возможности организма человека и увеличить продолжительность его активной жизни. 25

Основными целями УНИИФ являются: – научная разработка и совершенствование современной системы профилактики и диагностики туберкулеза, силикотуберкулеза, неспецифических заболеваний легких у взрослых и детей, проживающих в промышленном регионе, их лечение и реабилитация; – проведение фундаментальных и прикладных медико-биологических, медико-инженерных исследований по проблемам профилактики, диагностики, своевременного выявления туберкулеза всех локализаций, силикотуберкулеза, а также других болезней органов дыхания у взрослых и детей, их лечения и реабилитации; – совершенствование специализированной (в том числе высокотехнологичной) медицинской помощи населению. Для достижения данных целей УНИИФу необходимо выполнение таких задач, как: – проведение новых экспериментальных разработок; – осуществление образовательной деятельности по программам послевузовского образования; – содержание, разведение и подготовка лабораторных животных для медико-биологических исследований; – обеспечение правовой охраны результатов интеллектуальной деятельности института; – поддержание необходимой готовности к оперативному осуществлению мероприятий по социальной защите населения, пострадавшего от чрезвычайных ситуаций (ЧС); – организация фармацевтической деятельности, изготовление и хранение лекарственных средств; – оказание населению специализированной (в том числе высокотехнологичной) медицинской помощи; – проведение в институте санитарно-гигиенических и противоэпидемических мероприятий. Модель взаимосвязи миссии, целей и задач УНИИФ представлена на рис. 2. После осознания рассматриваемой проблемы (снижение эффективности стандартных мер по борьбе с туберкулезом) руководство УНИИФ поставило следующие стратегические цели на 2018–2021 годы: – разработка новых противотуберкулезных препаратов и поиск новых нелекарственных методов лечения; – совершенствование технологий хирургического лечения лекарственноустойчивого туберкулеза; – повышение осведомленности населения о легочных заболеваниях, туберкулезе и его профилактике. 26

Миссия

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

Цели

Задачи

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

Проведение новых экспериментальных разработок

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

Совершенствование специализированной (в том числе высокотехнологичной) медицинской помощи населению

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

Рис. 2. Модель взаимосвязи миссии, целей и задач УНИИФ 27

Для достижения поставленных стратегических целей в назначенный период требуется выполнение следующих задач: – проведение фундаментальных исследований по поиску новых методов лечения туберкулеза; – изготовление новых лекарственных средств, выполнение качественного и количественного анализа последних, разработка правил их хранения, получения и отпуска; – содержание, разведение, подготовка лабораторных животных для медико-биологических исследований; – приобретение нового высокотехнологичного хирургического оборудования; – обучение и повышение квалификации сотрудников института; – издание и распространение печатной продукции с описанием результатов научной деятельности УНИИФ; – организация и проведение конгрессов, съездов, конференций, семинаров и выставок в соответствии с профилем деятельности института; – организация образовательной деятельности по программам послевузовского образования. Модель взаимосвязи стратегических целей и задач УНИИФ представлена на рис. 3. Те аспекты деятельности организации, которые обеспечивают ее функционирование и достижение стратегических целей, называются факторами успеха (иначе – конкурентными преимуществами). Для УНИИФ факторами успеха являются: – социальная значимость данного учреждения для населения; – финансовая поддержка со стороны государства; – высокий уровень профессионализма сотрудников; – наличие высокотехнологичного оборудования для проведения научнотехнических исследований и лечения пациентов; – государственная значимость этой организации; – способность персонала к быстрому освоению новых технологий; – качественный и количественный анализ новых технологий и лекарственных средств. Ключевые показатели эффективности (англ. Key Performance Indicators) – это количественные показатели деятельности организации, работающие на достижение ее стратегических целей; количественно измеримые индикаторы фактически полученных результатов. Ключевыми показателями эффективности стратегической деятельности УНИИФ являются: – уменьшение показателя смертности населения от туберкулеза минимум на 2 % и увеличение числа ремиссий на 40 % в первые 2 года по результатам работы; 28

Задачи УНИИФ на 2018–2021 годы

Стратегические цели УНИИФ на 2018–2021 годы

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

Проведение фундаментальных исследований по поиску новых методов лечения туберкулеза Изготовление лекарственных средств, их качественный и количественный анализ, получение, хранение и отпуск Содержание, разведение, подготовка лабораторных животных для медико-биологических исследований

Совершенствование технологий хирургического лечения лекарственноустойчивого туберкулеза

Приобретение нового высокотехнологичного хирургического оборудования Обучение и повышение квалификации сотрудников УНИИФ Издание и распространение печатной продукции с результатами научной деятельности УНИИФ

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

Организация и проведение конгрессов, съездов, конференций, семинаров и выставок в соответствии с профилем деятельности института Организация образовательной деятельности по программам послевузовского образования

Рис. 3. Стратегические цели и задачи УНИИФ на 2018–2021 годы

– увеличение числа патентов УНИИФ на инновационные разработки на 10 % в период реализации стратегии; – рост числа научных публикаций сотрудников УНИИФ в российских и зарубежных изданиях на 30 % в период реализации стратегии. Модель бизнес-стратегии УНИИФ представлена на рис. 4. Анализ бизнес-стратегии УНИИФ показывает, что этот научно-исследовательский институт имеет грамотный план развития, включающий решение актуальных проблем, направленных на совершенствование организации противотуберкулезных мероприятий. 29

30

Организация образовательной деятельности по программам послевузовского образования

Высокий уровень профессионализма сотрудников

Повышение уровня взаимодействия между сотрудниками УНИИФ, поощрение их участия в научно-технических разработках, конференциях и в написании научных статей

Рост числа научных публикаций сотрудников УНИИФ в российских и зарубежных изданиях на 30 % в период реализации стратегии

Увеличение числа патентов УНИИФ на инновационные разработки на 10 % в период реализации стратегии

Уменьшение показателя смертности населения от туберкулеза минимум на 2 % и увеличение числа ремиссий на 40 % в первые 2 года по результатам работы

Ежемесячный анализ деятельности организации по оказанию медицинской помощи населению и отслеживание динамики числа больных в регионе

Качественный и количественный анализ новых технологий и лекарственных средств

Наличие высокотехнологичного оборудования для проведения научно-технических исследований и лечения пациентов

Ключевые показатели эффективности

Быстрое внедрение и освоение новых технологий персоналом

Финансовая поддержка со стороны государства

Стратегические требования

Государственная значимость организации

Социальная значимость для населения

Факторы успеха

Рис. 4. Бизнес-стратегия УНИИФ на 2018 год

Организация и проведение конгрессов, съездов, конференций, семинаров и выставок

Издание и распространение печатной продукции с результатами научной деятельности УНИИФ

Обучение и повышение квалификации сотрудников УНИИФ

Приобретение нового высокотехнологичного хирургического оборудования

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

Изготовление лекарственных средств, их качественный и количественный анализ, получение, хранение и отпуск

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

Стратегии

Моделирование уровня бизнес-архитектуры Бизнес-процессы делятся на 3 категории: – процессы управления (совокупность отдельных видов деятельности, направленных на обеспечение функционирования и развития бизнеса в интересах достижения стоящих перед ним целей); – основные процессы (процессы, определяющие доходы организации, то есть процессы, направленные на предоставление товаров или услуг, позволяющих получать прибыль); – обеспечивающие процессы (вспомогательные бизнес-процессы, создающие условия для выполнения основных процессов и фактически снабжающие ресурсами всю деятельность организации). Бизнес-процессы управления УНИИФ таковы: – стратегический менеджмент; – финансовое планирование; – организация и контроль основных процессов; – организация и контроль обеспечивающих процессов; – управление персоналом. Основными бизнес-процессами УНИИФ являются: – научно-исследовательская деятельность; – контроль оборота наркотических и психотропных веществ; – оказание населению специализированной медицинской помощи; – проведение противоэпидемических мероприятий; – издание и рассылка печатной продукции с описанием результатов научной деятельности института; – фармацевтическая деятельность; – ветеринарная деятельность; – создание информационных ресурсов по профилю; – образовательная деятельность; – заготовка, переработка, хранение донорской крови, обеспечение безопасности ее применения; – техническое обслуживание оборудования ионизирующих излучений и радиоизотопов короткого действия; – деятельность, связанная с использованием возбудителей инфекционных заболеваний; – мониторинг распространения туберкулеза и сочетанных инфекций (ВИЧ, гепатиты). Обеспечивающие бизнес-процессы УНИИФ: – административно-хозяйственное обеспечение; – юридическое обеспечение; – бухгалтерский и налоговый учет; – управление персоналом; – ИТ-обеспечение. 31

Бизнес-процессы УНИИФ направлены на выполнение следующих бизнес-функций: – управление основной деятельностью организации (бизнес-процессы управления); – выполнение работ и оказание медицинских услуг (основные бизнеспроцессы); – обеспечение функционирования организации (обеспечивающие бизнеспроцессы). Все бизнес-процессы УНИИФ и соответствующие им бизнес-функции представлены на рис. 5. Реализация стратегических целей обеспечивается соответствующими бизнес-процессами. Не подкрепленную бизнес-процессом цель достичь невозможно. Матрица взаимосвязи стратегических целей УНИИФ и бизнес-процессов представлена в табл. 6. Как было отмечено ранее, основные бизнес-процессы УНИИФ направлены на предоставление товаров или услуг. Институт оказывает услуги по 4 основным направлениям (рис. 6): – медицинская деятельность; – образовательная деятельность; – организационно-методическая деятельность; – фармакологическая деятельность. Медицинская деятельность в УНИИФ подразумевает оказание населению медицинских услуг по следующим основным направлениям: – врачебные консультации; – диагностика; – терапия; – хирургия. Образовательная деятельность в учреждении ведется по таким программам послевузовского образования, как: – аспирантура «Фтизиатрия» (очная, заочная); – ординатура «Фтизиатрия», «Торакальная хирургия»; – повышение квалификации руководящих специалистов. Организационно-методическая деятельность в УНИИФ включает: – проведение научно-технических исследований по государственным целевым программам; – организацию конгрессов, съездов, конференций и семинаров; – написание и публикацию научных статей; – издание печатной продукции, содержащей материалы о научной деятельности сотрудников института. 32

33

Административнохозяйственное обеспечение

Образовательная деятельность

Мониторинг распространения инфекций

Заготовка, переработка, хранение донорской крови, обеспечение безопасности ее применения

Оказание специализированной медицинской помощи

Управление персоналом

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

Техническое обслуживание оборудования ионизирующих излучений и радиоизотопов короткого действия

Финансовое планирование

Проведение санитарногигиенических и противоэпидемических мероприятий

ИТ-обеспечение

Охрана и безопасность

Рис. 5. Бизнес-процессы и бизнес-функции УНИИФ

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

Юридическое обеспечение

Обеспечивающие процессы

Ветеринарная деятельность

Контроль оборота наркотических средств и психотропных веществ

Организация и контроль обеспечивающих процессов

Основные процессы

Организация и контроль основных процессов

Создание информационных ресурсов по профилю

Фармацевтическая деятельность

Научноисследовательская деятельность

Стратегический менеджмент

Процессы управления

Обеспечение функционирования организации

Выполнение работ и оказание медицинских услуг

Управление основной деятельностью организации

Бизнес-функции

Таблица 6 Матрица связей стратегических целей и бизнес-процессов УНИИФ Стратегические цели

№ п/п

Бизнес-процессы

Разработка Повышение Совершенновых осведомствование противоленности технологий туберкулезных хирургического населения препаратов о легочных лечения и исследование лекарственно- заболеваниях, новых туберкулезе устойчивого нелекарственных и его туберкулеза методов профилактике лечения

1

Стратегический менеджмент

+

+

+

2

Организация и контроль основных процессов

+

+

+

3

Организация и контроль обеспечивающих процессов

+

+

+

4

Научно-исследовательская деятельность

+

+

+

5

Фармацевтическая деятельность

+

6

Создание информационных ресурсов по профилю

7

Контроль оборота наркотических средств и психотропных веществ

8

Ветеринарная деятельность

9

Образовательная деятельность

+

+

10 Оказание специализированной медицинской помощи 11 Заготовка, переработка, хранение донорской крови, обеспечение безопасности ее применения 12 Проведение санитарногигиенических и противоэпидемических мероприятий

+

13 Издание и распространение печатной продукции с описанием результатов научной деятельности сотрудников института

+

34

О к о н ч а н и е т а б л. 6 Стратегические цели

№ п/п

Бизнес-процессы

Разработка Повышение Совершенновых осведомствование противоленности технологий туберкулезных хирургического населения препаратов о легочных лечения и исследование лекарственно- заболеваниях, новых туберкулезе устойчивого нелекарственных и его туберкулеза методов профилактике лечения

14 Мониторинг распространения инфекций

+ +

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

+

17 Административно-хозяйственное обеспечение

+

+

+

18 Охрана и безопасность

+

+

+

19 Юридическое обеспечение

+

+

+

+

+

+

20 Бухгалтерский и налоговый учет 21 ИТ-обеспечение

К фармакологической деятельности УНИИФ относится: – изготовление и получение лекарственных препаратов; – хранение и отпуск лекарственных средств населению. Для эффективной организации деятельности данного учреждения руководству необходимо нанять сотрудников и грамотно распределить между ними бизнес-процессы. На данный момент главой УНИИФ является директор; в его непосредственном подчинении находятся: – заместитель директора по научной работе; – заместитель директора по организационно-методический работе (ОМР); – заместитель директора по медицинской части; – заместитель директора по клинико-экспертной работе и контролю качества медицинской помощи (КЭР И ККМП); 35

УСЛУГИ

Медицинская деятельность

Образовательная деятельность

Консультативные услуги

Аспирантура

Диагностические услуги Терапевтические услуги

Организационнометодическая деятельность Научнотехнические исследования

Фтизиатрия очная

Организация конгрессов и конференций

Фтизиатрия заочная Ординатура

Хирургические услуги

Фармакологическая деятельность Изготовление и получение лекарств Хранение и отпуск лекарственных средств

Написание научных статей

Повышение квалификации

Издание научной печатной продукции

Рис. 6. Услуги УНИИФ

– главный бухгалтер; – заместитель директора по экономическим вопросам; – заместитель директора по хозяйственным вопросам; – глава службы охраны труда; – начальник службы кадров и документационного обеспечения; – начальник отдела закупок; – начальник технического отдела; – главная медсестра; – заведующий научной библиотекой. В свою очередь, перечисленные должностные лица также имеют в своем подчинении различных специалистов: начальников отделов, заведующих отделениями, лабораториями, кабинетами и так далее. Моделью, демонстрирующей внутреннюю иерархию УНИИФ, является модель его организационной структуры. Она схематично отражает направления работы института, взаимосвязи сотрудников и распределение ответственности, прав и обязанностей (рис. 7). Матрица распределения ответственности показывает взаимосвязи между протекающими в институте бизнес-процессами и обязанностями сотрудников. 36

ДИРЕКТОР Заместитель директора по научной работе

Заместитель директора по ОМР

Заместитель директора по медицинской части

Заведующий лабораторией информационного обеспечения и организации противотуберкулезной работы

Начальник организационнометодического отдела

Заведующий консультативнодиагностическим отделением

Заведующий физиотерапевтическим кабинетом

Заведующий приемным отделением и отделением дифференциальной диагностики туберкулеза

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

Заведующий кабинетом функциональной диагностики Начальник клиники Заведующий централизованной стерилизацией Заведующий аптечным распределительным пунктом Заведующий патологическим отделением

Заведующий отделением лечения больных туберкулезом легких с лекарственной устойчивостью Заведующий туберкулезным отделением для больных костносуставным туберкулезом Заведующий отделением лечения больных туберкулезом Заведующий хирургическим отделением (для больных туберкулезом)

Заместитель директора по КЭР и ККМП

Заведующий туберкулезным легочнохирургическим отделением

Заведующий отделением анестезиологииреанимации и операционным блоком

Заведующий отделением лучевой диагностики и эндоскопическим кабинетом

Заведующий клиникодиагностической лабораторией

Главный бухгалтер Бухгалтер Заместитель директора по экономическим вопросам Начальник экономической службы Заместитель директора по хозяйственным вопросам Заведующий пищеблоком Заведующий гаражом и транспортными средствами Заведующий хозяйственной частью

Заведующий отделением микробиологии и ПЦРдиагностики

Рис. 7. Организационная структура УНИИФ 37

Глава службы охраны труда Начальник службы кадров и документационного обеспечения Начальник отдела закупок Начальник технического отдела Главная медсестра Заведующий научной библиотекой

Требуется провести работу по перераспределению обязанностей, если в матрице обнаружены: – процессы, не переданные на исполнение ответственным лицам; – лица, не ответственные ни за один бизнес-процесс; – несоответствие между важностью и сложностью процесса и количеством ответственных за него (перегрузка или недоработка сотрудников при исполнении ими своих обязанностей). Рассмотрим фрагмент матрицы распределения ответственности сотрудников УНИИФ за бизнес-процессы, протекающие в данном учреждении (табл. 7). По результатам анализа данного фрагмента матрицы распределения ответственности в УНИИФ (см. табл. 7) проблем в организации его деятельности на этом уровне не выявлено: все стратегические цели были связаны с отвечающими их достижению бизнес-процессами, за реализацию которых назначены ответственные лица, что говорит о грамотной организации работы института (при данной степени детализации модели бизнес-архитектуры). Моделирование уровня архитектуры приложений Для организации эффективной деятельности учреждения и эффективного управления им в УНИИФ используется комплекс сервисов и программного обеспечения (1С: Предприятие; Visocall IP; Федеральная электронная медицинская библиотека; Microsoft Office). Однако основным программным продуктом, применяющимся при выполнении большинства процессов в этом медицинском учреждении, является Единая государственная информационная система в сфере здравоохранения, которая создана для обеспечения эффективной информационной поддержки органов и организаций системы здравоохранения, а также граждан в рамках процессов управления медицинской помощью и ее непосредственного получения. Данная система включает 5 основных подсистем. Это: – централизованный сервис информирования о взаимодействии лекарственных средств; – подсистема мониторинга реализации федеральных целевых программ; – подсистема мониторинга реализации государственного задания по оказанию высокотехнологичной медицинской помощи за счет средств федерального бюджета; – подсистема ведения расписания приемов специалистов, проведения консультаций, в том числе телемедицинских, и загрузки мощностей организации, а также электронной записи на прием к врачу; – подсистема ведения интегрированной электронной медицинской карты и сервисов доступа к ней. Система 1С: предприятие служит для эффективного выполнения процессов управления деятельностью УНИИФ, а также части обеспечивающих бизнес-процессов. Установленные конфигурации: 1С: Бухгалтерия; 1С: Медицина; 1С: Кадры; 1С: Финансы и учет. 38

39

Краткое описание

Долгосрочное планирование деятельности организации

Оказание специализированной консультативнодиагностической помощи

Поиск и отбор кандидатов, прием на работу, увольнение Подготовка бухгалтерской и налоговой отчетности

Бизнес-процесс

Стратегический менеджмент

Оказание специализированной медицинской помощи

Управление персоналом

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

1

2

3

4

№ п/п Директор

+

+

Заместитель директора по экономическим вопросам

+

+

+

Главный бухгалтер

Заместитель директора по медицинской части

+

+

Заместитель директора по КЭР и ККМП

+

+

Заместитель директора по ОМР

+

Начальник службы кадров

+

+

+

Начальник технического отдела

Ответственный за процесс, должность

Фрагмент матрицы распределения ответственности в УНИИФ

+

Заместитель директора по хозяйственным вопросам

Таблица 7

+

Заведующий лабораторией информационного обеспечения и организации противотуберкулезной работы

40

Образовательная деятельность

Поддержка ИТ

Административнохозяйственное обеспечение

Мониторинг распространения инфекций

7

8

9

Финансовое планирование

Бизнес-процесс

6

5

№ п/п

Проведение мониторинга распространения туберкулеза и сочетанных инфекций (ВИЧ, гепатиты)

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

Создание и поддержка современной ИТ-инфраструктуры

Организация образовательной деятельности института

Экономический анализ хозяйственной деятельности, учет экономических показателей

Краткое описание

Заместитель директора по экономическим вопросам

+

Директор

+

Главный бухгалтер

Заместитель директора по ОМР

+

Начальник технического отдела

+

+

Заместитель директора по хозяйственным вопросам

Начальник службы кадров

Заместитель директора по КЭР и ККМП

Заместитель директора по медицинской части

Ответственный за процесс, должность

Окончание

т а б л. 7

+

Заведующий лабораторией информационного обеспечения и организации противотуберкулезной работы

Система Visocall IP предназначена для обеспечения внутреннего взаимодействия между всеми сотрудниками института. Базовый пакет приложений Microsoft Office (MS Word, MS Excel) используется при работе с большинством электронных документов и при подготовке печатной продукции о научной деятельности сотрудников УНИИФ. С помощью программного продукта Microsoft Project в УНИИФ выполняется стратегическое планирование. Федеральная электронная медицинская библиотека необходима для обеспечения всех направлений образовательной деятельности, которую ведет данное учреждение. Единая государственная информационная система в сфере здравоохранения используется сотрудниками УНИИФ при ведении большинства основных бизнес-процессов, требующих применения специализированных программных средств. Для установления взаимосвязей между приложениями и их функциями может быть построена соответствующая модель (рис. 8). Для оценки качества автоматизации бизнес-процессов может быть построена матрица связей бизнес-процессов и приложений (табл. 8). У каждого приложения имеются своя функция и свое целевое назначение, а следовательно, есть и определенные категории пользователей, у которых выполнение их должностных обязанностей непосредственно связано с использованием конкретных программных продуктов. Продемонстрировать эти взаимосвязи помогает матрица связей приложений и специалистов (табл. 9). Анализ связей приложений и специалистов (см. табл. 9) позволил выявить в УНИИФ следующие проблемы: 1) институт собирает информацию из диспансеров для дальнейшей аналитики, однако примерно половина диспансеров Приволжского и Уральского федеральных округов не включены в единую базу данных, большая часть первичной информации о случаях заболеваний поступает в УНИИФ на бумажных носителях и вводится в базы сотрудниками этого учреждения вручную; 2) отсутствует бизнес-процесс по оперативному контролю заболеваний, текущий процесс мониторинга осуществляется ежеквартально и не влечет оперативных решений и контроля над ситуацией. Уровень ИТ-инфраструктуры Для того чтобы деятельность УНИИФ была действительно эффективной, в институте требуется наличие правильно организованной инфраструктуры информационных технологий. Функциональная и надежная ИТ-инфраструктура играет важную роль в развитии любой организации и является основой ее жизнедеятельности, а также дает серьезное преимущество перед конкурентами. 41

42

Visocall IP

Приложения

Контроль за осуществлением государственных функций в области оказания высокотехнологичных медицинских услуг населению Обеспечение образовательной деятельности

Федеральная электронная медицинская библиотека

Обеспечение медицинской деятельности

Управление и планирование деятельности организации

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

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

Рис. 8. Связь между приложениями УНИИФ и их функциями

Подсистема мониторинга реализации федеральных целевых программ

Единая государственная информационная система в сфере здравоохранения

1С: Предприятие

Учет и предоставление информации по лекарственным средствам

Централизованный сервис информирования о взаимодействии лекарственных средств

Microsoft Project

Управление проектами и задачами

Функции приложений

Подсистема ведения интегрированной электронной медицинской карты и сервисов доступа к ней

Microsoft Office: MS Word, MS Excel

Обработка электронной документации

Организация коммуникации

Таблица 8 Фрагмент матрицы связей бизнес-процессов и приложений УНИИФ

Единая государственная информационная система в сфере здравоохранения

Долгосрочное планирование + деятельности организации

MS Word, MS Excel

Федеральная электронная медицинская библиотека

Краткое описание

Visocall IP

Бизнес-процесс

1С: Предприятие

№ п/п

Microsoft Project

Приложения

+

+

+

+

1

Стратегический менеджмент

2

Оказание Оказание специализированспециализированной ной консультативно-диагносмедицинской тической помощи помощи

3

Управление персоналом

Поиск и отбор кандидатов, прием на работу, координация работы, увольнение

+

4

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

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

+

+

5

Финансовое планирование

Экономический анализ хозяйственной деятельности, учет экономических показателей

+

+

6

Образовательная деятельность

Организация образовательной деятельности института

7

Поддержка ИТ

Создание и поддержка современной ИТ-инфраструктуры

+

+

8

Административнохозяйственное обеспечение

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

+

+

9

Мониторинг распространения инфекций

Сбор информации из диспансеров по заболеваемости, изучение и анализ показателей заболеваемости, отчетность, проведение мониторинга распространения туберкулеза и сочетанных инфекций (ВИЧ, гепатиты) 43

+

+

+

+

+

+

Таблица 9 Фрагмент матрицы связей приложений и специалистов УНИИФ

MS Word, MS Excel

Единая государственная информационная система в сфере здравоохранения

+ +

+

+

Финансовое планирование и контроль за госфинансами, выделенными на оказание медицинской помощи и проведение исследовательской работы, взаимодействие с директором и подчиненными

+

+

+

+

Ведение бухгалтерского и налогового учета, взаимодействие с директором и подчиненными

+

+

+

Заместитель Организация, распределение директора и контроль медицинской попо медицинской части мощи, анализ результатов

+

+

+

5

Заместитель директора по КЭР и ККМП

Выполнение клинико-экспертных работ и контроль качества медицинской помощи

+

+

+

6

Заместитель директора по ОМР

Обеспечение, подготовка и проведение образовательных программ

+

7

Начальник службы кадров

Разработка кадровой политики и кадровой стратегии, осуществление работ по подбору, отбору и расстановке

Пользователь (должность)

Краткое описание цели использования приложения

1

Директор

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

2

Заместитель директора по экономическим вопросам

3

Главный бухгалтер

4

44

+

+

Федеральная электронная медицинская библиотека

1С: Предприятие

+

№ п/п

Visocall IP

Microsoft Project

Приложения

+

+

+

Окончание

т а б л. 9

Единая государственная информационная система в сфере здравоохранения

MS Word, MS Excel

Федеральная электронная медицинская библиотека

Краткое описание цели использования приложения

Visocall IP

Пользователь (должность)

1С: Предприятие

№ п/п

Microsoft Project

Приложения

кадров на основе оценки личных и деловых качеств работников, контроль правильности их использования в подразделениях 8

Начальник Осуществление технической технического отдела и ИТ-поддержки УНИИФ

9

Заместитель директора по хозяйственным вопросам

10 Заведующий лабораторией информационного обеспечения и организации противотуберкулезной работы

+

+

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

+ +

+

Сбор информации из диспансеров, изучение и анализ показателей заболеваемости, квартальная отчетность, мониторинг распространения инфекций

+

+

ИТ-инфраструктура – это организационно-техническое объединение программных, вычислительных и телекоммуникационных средств, связей между ними и эксплуатационным персоналом, обеспечивающее предоставление информационных, вычислительных и телекоммуникационных ресурсов, возможностей и услуг работникам (подразделениям) предприятия (орга45

низации), необходимых для осуществления профессиональной деятельности и решения соответствующих бизнес-задач. ИТ-инфраструктура УНИИФ состоит: – из компьютеров; – сервера; – маршрутизаторов; – различной оргтехники (принтеры, сканеры и т. д.) (рис. 9). Файловый сервер

Другие отделения Интернет

Технический отдел

Бухгалтерия

Исследовательская лаборатория

Рис. 9. ИТ-инфраструктура УНИИФ

Все новые данные в УНИИФ записываются и хранятся на файловом сервере, их передача осуществляется по локальной сети через маршрутизаторы, расположенные в каждом отделении на автоматизированных рабочих местах сотрудников института. Такая ИТ-инфраструктура является логичной, удобной и функциональной, что способствует высокому общему темпу работы во всех отделениях УНИИФ и обеспечивает: – быстрый обмен данными между подразделениями; – использование общих ресурсов, находящихся в сети; – доступ в глобальную сеть; – использование рабочей электронной почты. Недостатком, однако, является то, что документы прошлых лет и данные медицинской статистики хранятся только в бумажном виде в архиве института и в его отделениях и, соответственно, не учитываются при ретроспективном (оценочном) анализе. 46

Анализ полной модели архитектуры УНИИФ Полная модель архитектуры организации включает иерархию всех составляющих ее уровней и моделей. Архитектура УНИИФ на уровне бизнесстратегии содержит модель взаимосвязи миссии, целей и задач (см. рис. 2), стратегические цели и задачи (см. рис. 3), бизнес-стратегию (см. рис. 4); на уровне бизнес-архитектуры находятся бизнес-процессы и бизнес-функции (см. рис. 5), услуги (см. рис. 6), организационная структура (см. рис. 7); на уровне приложений – связь между приложениями (см. рис. 8), матрица распределения ответственности (см. табл. 7), матрица связей бизнес-процессов и приложений (см. табл. 8), матрица связей приложений и специалистов (см. табл. 9); на уровне ИТ-инфраструктуры рассматривается ИТ-схема (см. рис. 9). Анализ полной модели архитектуры УНИИФ показал, что институт ведет весьма разноплановую деятельность. При этом каждое ее направление так или иначе требует анализа каких-либо данных. И именно в организации процесса анализа данных выявлены наиболее серьезные проблемы (всего их три). Проблема 1. Долгая доставка данных медицинской статистики из диспансеров. Последствия: до УНИИФ оперативная и сводная информация доходит с большой задержкой, что негативно влияет на контроль заболеваний в целом. Причины: около половины диспансеров Приволжского и Уральского федеральных округов не включены в единую базу данных, большая часть первичной информации о случаях заболеваний поступает в УНИИФ на бумажных носителях. Проблема 2. Недостаточный контроль выполнения мероприятий по купированию отдельных очагов заболевания. Последствия: образуются очаги заболеваний высокой степени опасности, что приводит к распространению инфекций. Причины: отсутствует бизнес-процесс по оперативному контролю заболеваний, текущий процесс мониторинга осуществляется ежеквартально и не влечет оперативных решений и контроля над ситуацией. Проблема 3. Неточное прогнозирование распространения заболеваний. Последствия: вспышки инфекций в тех локациях, где не было предпосылок для их появления. Причины: отсутствие единой базы ретроспективных данных об очагах инфекций для построения прогнозных моделей; документы прошлых лет и данные медицинской статистики не перенесены в единую базу данных и хранятся в УНИИФ только в бумажном виде в архиве учреждения и в его отделениях и, соответственно, не учитываются при ретроспективном (оценочном) анализе. С целью более подробного изучения бизнес-процесса анализа данных в УНИИФ, уточнения и конкретизации требований к решению рассматриваемой проблемы дополнительно были построены и изучены модели бизнес-процессов AS-IS («как есть»). 47

Дополнение уровня бизнес-архитектуры УНИИФ: моделирование AS-IS бизнес-процесса анализа данных Построение функциональной модели AS-IS позволяет четко зафиксировать, какие именно процессы осуществляются в организации, как они выполняются, какие информационные объекты используются при реализации функций различных уровней детализации и многое другое. Благодаря анализу функциональной модели AS-IS можно понять, в чем заключается проблемная ситуация, в чем будут состоять преимущества новых процессов и каким изменениям подвергнется существующая структура организации рассматриваемого процесса. Ниже (рис. 10) представлен нулевой уровень процесса анализа данных в УНИИФ согласно методологии функционального моделирования и графической нотации IDEF0. На входе расположены входящие потоки: «Необходимость в сохранении здоровья населения» и «Список необходимых данных», исполнительными лицами являются представители медицинского персонала, управляется данный процесс документом с описанием существующих проблем, стандартными требованиями предприятия и Федеральным законом «О персональных данных», а на выходе процесса находится документ со списком мероприятий для сохранения здоровья населения. Далее (рис. 11) представлен первый уровень процесса анализа данных в УНИИФ. Он тоже выполнен в нотации IDEF0 и включает следующие составляющие: сбор информации по текущей ситуации; обработка данных; принятие решения. Второй уровень модели AS-IS процесса анализа данных (рис. 12) включает следующие составляющие: структурирование информации; сопоставление и построение зависимостей между данными; формулировка и запись выводов. Данный уровень, в отличие от первого, построен в нотации DFD (это методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки и хранилища данных, к которым осуществляется доступ). Изучение процесса анализа данных в УНИИФ позволяет сделать вывод, что основными проблемными этапами являются сбор информации по текущей ситуации и обработка данных, а именно структурирование, сопоставление и построение зависимостей между ними. Основная проблема этапа сбора информации заключается в отсутствии централизованного хранения всех данных: относительно новая информация хранится в электронном виде, а документы прошлых лет и медицинская статистика существуют лишь в бумажном виде и хранятся в архиве учреждения, а также в его различных отделениях, лабораториях и кабинетах. Поэтому в большинстве случаев процесс сбора данных выглядит следующим образом: сначала медицинский работник отбирает документы, которые существуют в электронном виде, затем он длительное время вручную 48

49

»

Рис. 10. IDEF0 «Анализ данных в УНИИФ (AS-IS)», нулевой уровень

«

50

»

Рис. 11. IDEF0 «Анализ данных в УНИИФ (AS-IS)», первый уровень

«

51

»

Рис. 12. DFD «Анализ данных в УНИИФ (AS-IS)», второй уровень

«

отыскивает все необходимые документы в архиве и составляет список недостающей информации, после чего начинает поиск этих документов по отделениям, лабораториям и кабинетам, при этом часто оказывается, что какие-то документы утеряны, и требуется их восстановление. Главной проблемой процесса обработки данных является его длительность: медицинскому работнику необходимо прочитать и структурировать большое количество документов разных типов, которые состоят из сплошного текста и таблиц, а затем всю информацию сопоставить и сделать выводы для принятия решения. Это занимает огромное количество времени и зачастую получается так, что пока медицинский работник данные анализировал, они стали неактуальными, и полученные по ним выводы практически лишены смысла. Таким образом, для автоматизации в УНИИФ бизнес-процесса анализа данных, для повышения уровня организации противотуберкулезных мероприятий и контроля распространения туберкулеза в регионе был запущен ИТ-проект, целью которого являлись разработка и внедрение ГИС «Очаги туберкулеза». Выбор такого решения был обусловлен отсутствием на рынке готового приложения, дающего возможность решить поставленные в проекте задачи. Проведенное предпроектное обследование позволило конкретизировать рассматриваемую проблему (табл. 10). Т а б л и ц а 10 Первоначальная постановка обнаруженной в УНИИФ проблемы № п/п

Описание

Элемент

1

Проблема

Снижение эффективности стандартных мер по борьбе с туберкулезом

2

Объект негативного воздействия проблемы

Население ПФО и УрФО

3

Результат воздействия

Распространение туберкулеза в масштабах ПФО и УрФО

4

Способ решения проблемы

Разработка комплексного решения для автоматизации сбора и анализа данных со всех диспансеров – ГИС «Очаги туберкулеза»

5

Последствия предлагаемого решения

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

Также было сформулировано бизнес-требование к решению рассматриваемой проблемы: разработка и внедрение в УНИИФ ГИС «Очаги туберкулеза» (ГИС ОТБ) должны замедлить распространение туберкулеза в ПФО и УрФО и снизить смертность населения от данной инфекции минимум на 2 % путем автоматизации процессов анализа данных и внедрения оперативного мониторинга и контроля заболеваемости в первые 2 года после внедрения. Выявление критериев и ограничений проекта Перед началом разработки информационной системы необходимо определить ограничения, в рамках которых будет реализован проект (табл. 11). Т а б л и ц а 11 Ограничения ИТ-проекта разработки ГИС «Очаги туберкулеза» № п/п

Источник ограничений

1

Экономический

Образцы вопросов для выявления ограничений

Какие финансовые или бюджетные ограничения следует учесть? Для разработки планируется использование средств федерального бюджета и частных инвестиций. Бюджет формируется из реальной стоимости разработки ГИС. Существуют ли соображения, касающиеся себестоимости и ценообразования? Себестоимость будет определяться исходя из цены аппаратной части и зарплат участников проекта. Существуют ли вопросы лицензирования? В проекте используются технологии Оpen source и другое свободно распространяемое программное обеспечение, соответственно в этом проекте правовое поле не будет нарушено. Функционирование ГИС ОТБ как государственного веб-сервиса будет осуществляться на основе Федерального закона Российской Федерации «Об организации предоставления государственных и муниципальных услуг» от 27 июля 2010 года № 210-ФЗ. Коммерческое лицензирование программного продукта не предусматривается. Отдельные компоненты ГИС могут быть запатентованы при выявлении в них объектов интеллектуальной собственности. Существует ли проект информационной системы и какой экономический выигрыш он должен принести (увеличение прибыли в / на сколько)? Существенный экономический выигрыш состоит в экономии средств федерального бюджета за счет снижения уровня заболеваемости, поскольку стоимость лечения одного пациента составляет в среднем 1 миллион рублей 53

Продолжение № п/п

2

Источник ограничений

Политический

т а б л.

11

Образцы вопросов для выявления ограничений

Существуют ли внешние или внутренние политические вопросы, влияющие на потенциальное решение о разработке системы? Для внедрения ГИС ОТБ в ПФО и УрФО потребуется политическая воля уровня министерств здравоохранения соответствующих субъектов РФ. Существуют ли в УНИИФ проблемы в отношениях между подразделениями? Выявлена проблема несвоевременного и неполного обмена информацией между медицинскими службами. Существует ли проект информационной системы и какой политический эффект он может оказать (снижение числа конфликтов в / на сколько раз?) Миссия реализации ГИС ОТБ – повышение качества жизни граждан и снижение социальной напряженности

3

Технический

Существуют ли ограничения в выборе технологий? В проекте не будут использоваться технологии некоторых крупных компаний из недружественных стран ввиду их малопредсказуемого поведения на рынке России. Должны ли мы работать в рамках существующих платформ или технологий? Клиентская часть информационной системы будет реализована в виде веб-интерфейса, поэтому приложение – кроссплатформенное. Запрещено ли использование любых новых технологий? Будут использованы любые технологии Оpen Source, оптимальные для проекта. Должны ли мы использовать какие-либо закупаемые пакеты программного обеспечения? Не планируется

4

Системный

Будет ли решение в виде информационной системы создаваться для наших существующих систем? Будут реализованы интерфейсы ГИС ОТБ с другими медицинскими ИС для получения данных медицинской статистики. Более глубокой интеграции не планируется. Должны ли мы обеспечивать совместимость с существующими решениями в виде текущей информационной системы? Только для реализации интерфейсов передачи данных ГИС. Какие операционные системы и среды должны поддерживаться? Все существующие операционные системы общего назначения. 54

Окончание № п/п

Источник ограничений

т а б л.

11

Образцы вопросов для выявления ограничений

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

Правовой

Существуют ли ограничения информационной среды или правовые ограничения? Информационная среда ограничена данными медицинской статистики, поэтому следует принимать во внимание правовые нормы регламентов медицинских служб. Каковы юридические ограничения? Основными ограничениями являются ФЗ-153 «О персональных данных», а также регламенты работы медицинских служб. Накладывают ли ограничения требования безопасности? Если да, то какие именно? Информация, заносимая в ГИС ОТБ, не является конфиденциальной, однако она в основном предназначена для внутреннего применения, поэтому будет реализована авторизация для пользователей разных уровней. Какими другими стандартами мы ограничены? Проект по своим требованиям не должен выходить за рамки федеральных ГОСТов и стандартов

6

График и ресурсы

Определен ли график разработки информационной системы? Какие конкретные сроки нужно соблюсти? Реализацию в Свердловской области пилотного проекта ГИС ОТБ планируется провести в течение года. Ограничены ли мы существующими ресурсами? Основными ресурсами являются: денежные средства, кадры и аппаратные комплектующие. Для реализации ГИС ОТБ будут привлечены средства федерального бюджета и частные инвестиции, задействованы кадры из УрФУ, а также частные специалисты. Существенных ограничений не предвидится. Можем ли мы привлекать работников со стороны? Будут задействованы профильные специалисты со стороны для разработки наиболее узких направлений (асинхронное программирование, векторная графика). Можем ли мы увеличить штат? Если да, то на временной основе или на постоянной? Планируется временное увеличение штата для реализации проекта 55

Разработка концепции ГИС «Очаги туберкулеза» Выявление акторов, заинтересованных лиц и пользователей ГИС ОТБ, как и любая другая информационная система, должна удовлетворять требования заинтересованных в ней лиц (табл. 12). Т а б л и ц а 12 Категории заинтересованных в ГИС ОТБ лиц № п/п

Категория

Описание

1

Пользователи системы

Участковый врач УНИИФ, главврачи диспансеров, главный фтизиатр УНИИФ

2

Непрямые пользователи

Министерства здравоохранения субъектов РФ в ПФО и УрФО, СЭС

3

Лица, на которых воздействуют бизнес-последствия реализации системы

Население РФ

4

Лица, которые воздействуют на реализацию системы

Команда разработчиков УрФУ и Уральского государственного медицинского университета

Акторами же ГИС ОТБ являются все прямые пользователи и система 1С: Медицина, с которой необходимо обеспечить интеграцию. Модель процесса анализа данных УНИИФ TO-BE Ввод в эксплуатацию ГИС «Очаги туберкулеза» должен устранить в УНИИФ выявленные в ходе анализа недостатки модели AS-IS, оптимизировать процесс анализа данных и в целом значительно повысить эффективность всех направлений деятельности института. Для того чтобы рассмотреть, как должен выглядеть данный бизнеспроцесс после введения в деятельность УНИИФ ГИС «Очаги туберкулеза», необходимо построить функциональную модель TO-BE («как должно быть»), которая создается на основе модели AS-IS, с исправлением недостатков в существующей организации бизнес-процессов, а также с их совершенствованием и оптимизацией. Перед построением модели TO-BE, чтобы учесть в ней все необходимые изменения исходя из поставленных ранее ограничений, были выявлены основные требования пользователей системы. Использование в деятельности УНИИФ ГИС «Очаги туберкулеза» должно позволить: – обеспечить централизованное хранение всех данных и быстрый доступ к ним медицинского персонала с любого автоматизированного рабочего места; 56

– автоматизировать и значительно ускорить процесс обработки необходимых данных; – предоставлять данные в максимально удобном и понятном визуализированном виде, что обеспечит ускорение процесса формулировки медицинскими работниками выводов по текущей ситуации и принятия необходимых решений; – значительно повысить эффективность деятельности сотрудников института. Представим выполненный в нотации IDEF0 нулевой уровень процесса анализа данных модели TO-BE в УНИИФ с учетом требований пользователей и известных ограничений (рис. 13). На входе модели располагаются статистические блоки «Необходимость в сохранении здоровья населения» и «Данные ГИС ОТБ». Исполнительными лицами должны стать представители медицинского персонала, которые будут использовать в своей деятельности программные средства ГИС «Очаги туберкулеза». Управляться данный процесс должен документом с описанием существующих проблем, стандартными требованиями предприятия и Федеральным законом «О персональных данных». На выходе модели процесса находится документ со списком мероприятий для сохранения здоровья населения. Главным изменением на нулевом уровне бизнес-процесса анализа данных в УНИИФ выступает появление ГИС «Очаги туберкулеза» как программного обеспечения, которое используют исполнительные лица – представители медицинского персонала. Благодаря корректировке процесса изменятся и входные данные: теперь вместо списка необходимой информации на вход должны поступать сразу данные, хранящиеся в ГИС «Очаги туберкулеза». Представим первый уровень процесса анализа данных модели TO-BE в УНИИФ (рис. 14), который также выполнен в нотации IDEF0 и состоит из следующих работ: «Отбор необходимых данных информационной системой», «Обработка данных» и «Принятие решения». Принципиальное отличие заключается в первой работе: теперь вместо сбора необходимой информации медицинским персоналом ГИС «Очаги туберкулеза» самостоятельно будет отбирать из базы все необходимые для анализа данные. Далее (рис. 15) рассмотрим второй уровень модели TO-BE процесса анализа данных в нотации DFD, который содержит в себе следующие работы: «Автоматическое структурирование данных», «Сопоставление и визуализация данных системой», «Формулировка и запись выводов». Второй уровень модели ТО-ВЕ претерпел самые большие изменения. Вся информация будет выгружаться и автоматически структурироваться из базы данных ГИС «Очаги туберкулеза»; далее структурированные данные с помощью 57

58

»

Рис. 13. IDEF0 «Анализ данных в УНИИФ (TO-BE)», нулевой уровень

«

59

Рис. 14. IDEF0 «Анализ данных в УНИИФ (TO-BE)», первый уровень

«

»

60

»

Рис. 15. DFD «Анализ данных в УНИИФ (TO-BE)», второй уровень

«

средств этой же ГИС будут сопоставляться и визуализироваться, а затем выводиться на монитор медицинскому сотруднику института. Медсотрудник должен иметь возможность изучить обработанные и удобно визуализированные данные, а затем сформулировать и записать на их основе все необходимые выводы для последующего принятия решения по существующей проблеме. Функциональные требования к ГИС «Очаги туберкулеза» 1. Система должна предоставлять пользователям возможность масштабируемой навигации по картографическим объектам. 2. Пользователь должен иметь возможность оценить ситуацию с распространением туберкулеза: – в интересующей области Российской Федерации (осуществить выбор области, получить данные о количестве в ней районов и населенных пунктов, о численности и плотности населения, об общем количестве очагов заболевания и о количестве очагов по каждой группе); – в интересующем районе (осуществить выбор района, получить данные о численности в нем населения, о количестве очагов и показателе эпидемиологической напряженности, о количестве очагов по каждой группе и процентном отклонении от среднего показателя по области); – по конкретной группе заболеваний (выбрать группу заболеваний, получить список районов с данными о количестве в них очагов туберкулеза конкретной группы и показателе эпидемиологической напряженности). 3. Пользователь должен иметь возможность оценить ситуацию с выполнением мероприятий по противодействию активному распространению туберкулеза конкретной группы в выбранном районе области, в населенном пункте, по конкретному адресу: осуществить выбор группы туберкулеза, увидеть дату назначения мероприятия, статус выполнения мероприятия, причину невыполнения мероприятия. Требования к интерфейсам пользователя и внешним интерфейсам 1. Система должна иметь векторный графический веб-интерфейс для масштабируемой навигации по картографическим объектам. 2. Переходы между уровнями федеральных округов, уровнями субъектов Российской Федерации и уровнями районов должны реализовываться в графическом интерфейсе путем плавной анимации. 3. Геоинформационная онлайн-система должна отображать индикативную информацию об уровне эпидемиологической напряженности во всех территориальных субъектах, перечисленных в пункте 2, а также в отдельных очагах заболевания. 4. В графическом интерфейсе должна быть отражена информация о количестве очагов в субъекте по каждой группе опасности, о количественном приросте новых инфекционных очагов в днях и месяцах, а также об общем количестве очагов и общей численности населения в субъекте. 61

5. Система должна обеспечивать подачу данных на графический интерфейс в режиме реального времени и в этом же режиме пересчитывать показатель эпидемиологической напряженности. 6. Система должна отображать картографическую информацию и информацию, указанную в пункте 4, согласно группам очагов опасности. 7. Клиентская часть системы должна быть оптимизирована для работы на ЭВМ отдельных диспансеров. 8. Источником данных для системы должна являться база данных консолидированных показателей медицинской статистики 1С: Медицина. Нефункциональные требования Атрибуты качества: 1) время обновления данных в графическом интерфейсе системы должно составлять не более 5 000 миллисекунд; 2) время перехода интерфейса из одного состояния в другое не должно превышать 1 000 миллисекунд; 3) система должна быть реализована только на технологиях Оpen Source; 4) при выборе и закупке аппаратной части для ГИС ОТБ следует отдавать предпочтение отечественным электронным товарам. Бизнес-правила: 1) в графическом интерфейсе должен быть реализован мониторинг контроля за выполнением мероприятий по предотвращению распространения инфекционного заболевания (в соответствии с Федеральным законом от 18 июня 2001 г. № 77-ФЗ «О предупреждении распространения туберкулеза в Российской Федерации»); 2) база данных серверной части ГИС ОТБ должна быть реализована с помощью системы управления базами данных (СУБД), удовлетворяющей требованию по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации (в редакции приказов Федеральной службы по техническому и экспортному контролю России от 9 августа 2018 г. № 138, от 26 марта 2019 г. № 60, от 20 февраля 2020 г. № 35)7. Таким образом в число ключевых особенностей ГИС «Очаги туберкулеза» войдут: – потенциал для выработки наиболее оптимальной стратегии в борьбе с туберкулезом путем установления объективных географических данных о локализации его очагов; 7

См., например: О внесении изменений в Требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации, утвержденные приказом Федеральной службы по техническому и экспортному контролю от 25 декабря 2017 г. № 239 : приказ ФСТЭК России от 20 февраля 2020 г. № 35 // Легаласт : юридическая информационная система : сайт. URL: https://legalacts.ru/doc/prikazfstek-rossii-ot-20022020-n-35-o-vnesenii/?ysclid=lmgc8x85jl626704593 (дата обращения: 12.07.2023). 62

– возможность улучшения подготовки принятия решений для более эффективного распределения ресурсов (медицинских кадров, материального обеспечения, бюджетных средств); – высокая скорость доставки и обработки данных медицинской статистики; – географическая визуализация, позволяющая просто и доступно представлять большие объемы статистических и аналитических данных. Основным методом интеллектуального анализа в ГИС «Очаги туберкулеза» станет визуализация данных. Для пользователей методы визуализации очень важны, поскольку они отображают массивные данные в понятном виде. Благодаря визуализации данные из символического их представления трансформируются в графическое, доносящее до пользователя сложную и объемную информацию ясно, точно и эффективно. Основная цель визуализации данных состоит в том, чтобы задействовать перцептивные и когнитивные способности человека, позволяющие решить поставленную перед ним задачу. Иными словами, визуализация дает пользователю возможность легко понимать и интерпретировать разнотипные массивы информации. Сегодня в любом медицинском учреждении хранится огромное количество разнообразных статистических данных, и зачастую из них можно получить очень важную для специалистов информацию. Тем не менее документы с такими данными остаются невостребованными и оседают в архивах, поскольку медицинским работникам очень сложно обрабатывать большие объемы информации. Визуализация данной информации позволит оптимизировать и значительно повысить эффективность работы специалистов сферы здравоохранения, причем по разным медицинским направлениям. Функциональные возможности ГИС «Очаги туберкулеза» позволят медицинским учреждениям обрабатывать и визуализировать данные, напрямую или косвенно связанные с информацией о распространении туберкулеза, о его профилактике и противодействии ему. При этом данная информационная система проектируется как максимально понятное и простое в освоении программное средство, предназначенное для обеспечения деятельности специалистов сферы здравоохранения.

1.3. Проектирование информационной системы Проектирование информационной системы подразделяется на проектирование техническое и проектирование рабочее. Цель технического проектирования информационной системы – подготовка к этапу настройки и разветвления ее модулей. Соответственно техническое проектирование включает разработку организационной и функ63

циональной структуры модулей системы, определение уровня автоматизации информационного процесса, определение структуры информационного и технического обеспечения и требований к их элементам, постановку и алгоритмизацию задач обработки данных, разработку системы ведения нормативно-справочной базы. Иными словами, техническое проектирование предполагает детальную подготовку к этапу настройки / развертывания модулей информационной системы, для чего требуется решить следующие задачи: 1) сформировать список модулей и функций системы, необходимых для автоматизируемых бизнес-процессов; 2) сформировать список справочников будущей системы и, если применимо, текущей для дальнейшего переноса и обновления данных; 3) определить примерный сценарий работы системы по категориям пользователей для формирования необходимого набора диалогов и процедур проектируемой системы (включая реакции на все возможные, в том числе и маловероятные, действия со стороны пользователя); 4) определить элементы интерфейса пользователей (в случае гибкого или разрабатываемого «с нуля» решения) для достижения удобства работы с системой; 5) сформировать список отчетов / панелей мониторинга (включая их формы и обязательные для реализации элементы); эти отчеты в дальнейшем будут использоваться как для учетных целей, так и для целей мониторинга системы ее администратором (в части формирования и сбора статистики относительно нагрузки на ее отдельные модули, свободных ресурсов, активности пользователей и т. п.); 6) определить перечень настроек функциональных компонентов системы в соответствии с выделенными требованиями; 7) определить необходимость, возможности и пути интеграции проектируемой системы с существующими и планируемыми к реализации системами в организации заказчика, чтобы своевременно предусмотреть требующиеся для этого технические средства. После детального определения и согласования всех вышеописанных задач необходимо к моменту начала следующего этапа проектирования выбрать и подготовить также среду для разработки, тестирования и развертывания проектируемой информационной системы. В организационном аспекте к этому моменту должны быть подготовлены иерархическая структура работ, базовый календарный план и дорожная карта, позволяющие управлять проектом на протяжении всей его реализации. Результаты технического проектирования оформляются в виде технического проекта (проектного решения на автоматизацию модуля системы, представляющего собой задание на программирование). Техническое про64

ектирование, создание, настройка, доработка и внедрение модуля информационной системы осуществляются только на основании соответствующих утвержденных технических заданий (проектных решений). Технический проект – это документ, содержащий описание функциональных компонентов информационной системы, необходимых для реализации бизнес-процессов, описанных на этапе подготовки проектного решения, а также необходимых доработок системы и (при необходимости) процедур ее интеграции с модулями (или внешними системами), внедренными ранее. Перечень документов, создаваемых на стадии технического проектирования, определяется ГОСТом 34.201-89. Основная задача данной стадии – разработка архитектуры информационной системы и технических решений по ее реализации. При рабочем проектировании могут составляться блок-схемы, сценарии и алгоритмы для программных модулей. В целях снижения риска создания не соответствующей требованиям и техническому проекту информационной системы предварительно можно создать ее прототип для проверки предлагаемых архитектурных, функциональных, интерфейсных решений на практике совместно с будущими пользователями. Обратная связь в рамках прототипирования, организованная на первых этапах жизненного цикла, очень важна для устранения замечаний по итогам проектирования и доработки системы в интересах ее пользователей и заказчиков. В первую очередь создается макет, а уже потом проводятся тестирование, обсуждение и внесение корректировок в спецификации и прототип. Ко времени старта разработки информационной системы, как уже было сказано, должна быть выбрана и подготовлена среда для данной деятельности, а также определена методология, согласно которой будет осуществляться управление разработкой. От методологии зависит очень многое: принцип взаимодействия внутри команды разработки и внедрения, а также принцип ее взаимодействия с основными стейкхолдерами проекта; следование одной из моделей жизненного цикла ИС (каскадной, итерационной и пр.); длительность самого процесса разработки и тестирования и прочие важные аспекты проектирования системы.

Выбор модели жизненного цикла программного обеспечения для ИТ-проекта Институтом качества программного обеспечения SQI (Software Quality Institute, США) специально для выбора модели жизненного цикла ПО предложена схема классификации проектов по разработке информационных систем. Основу данной классификации составляют четыре категории критериев. Категория 1. Характеристики требований к ИТ-проекту. Критерии данной категории позволяют классифицировать проекты согласно требованиям пользователя (заказчика) к разрабатываемой информационной системе. 65

Например, известны ли требования к началу разработки и внедрения проекта, сложны ли они, будут ли изменяться. Категория 2. Характеристики команды разработчиков. Чтобы иметь возможность пользоваться при классификации ИТ-проектов критериями данной категории, состав команды разработчиков необходимо сформировать до выбора модели жизненного цикла программного обеспечения. Характеристики команды разработчиков играют важную роль при выборе модели, поскольку именно разработчики несут основную ответственность за успешную реализацию проекта. В первую очередь следует учитывать квалификацию разработчиков, их знакомство с предметной областью, инструментальными средствами разработки и т. п. Категория 3. Характеристики пользователей (заказчиков). Для того чтобы иметь возможность пользоваться критериями данной категории, еще до выбора модели жизненного цикла программного обеспечения необходимо определить возможную степень участия пользователей (заказчиков) в процессе разработки ИТ-проекта и их взаимосвязь с командой разработчиков на всем протяжении его эксплуатации. Это важно, поскольку отдельные модели жизненного цикла программного обеспечения для ИТ-проекта требуют активного участия пользователей в процессе их разработки. Выбор таких моделей при отсутствии у пользователей реальной возможности участвовать в проекте приведет к существенному снижению его качества. Категория 4. Характеристики типов проектов и рисков. В одних моделях управлению рисками уделяется достаточно большое внимание, а в других управление рисками вообще не предусматривается. Поэтому при выборе модели жизненного цикла программного обеспечения для ИТ-проекта следует учитывать его реальные риски, критичность и сложность продуктов разработки. Критерии данной категории отражают различные виды рисков, в том числе риски, связанные со сложностью проекта, с достаточностью ресурсов для его выполнения, с графиком реализации проекта и т. д. С учетом этого обеспечивается выбор модели, минимизирующей выявленные риски. Процедура выбора модели жизненного цикла программного обеспечения согласно SQI базируется на применении четырех таблиц, в каждой из которых представлена одна из категорий классификации проектов (табл. 13–16). Вопросы и ответы в этих таблицах (строки) позволяют охарактеризовать представленные в них модели жизненного цикла программного обеспечения для ИТ-проекта. Столбцы данных таблиц отражают обобщенные модели жизненного цикла и фактически представляют стратегии разработки информационной системы. При этом под RAD-моделью подразумевается независимая модель, не встроенная в другие модели жизненного цикла. С подробным описанием особенностей моделей жизненного цикла ИС мож66

но ознакомиться в учебном пособии «Управление жизненным циклом информационных систем»8. Рассматриваемая процедура включает четыре последовательно выполняемых действия. 1. Оценить специфику анализируемого проекта по критериям четырех категорий, представленным в виде вопросов (см. табл. 13–16). 2. Ответить на каждый представленный в табл. 13–16 вопрос, указав «да» или «нет» в соответствующих строках и столбцах таблиц применительно к анализируемому проекту. 3. Расположить категории критериев (анализируемые таблицы) и / или критерии, относящиеся к каждой категории (вопросы внутри таблиц), по степени важности для анализируемого проекта с целью выбора модели его жизненного цикла. 4. Выбрать из указанных в столбцах табл. 13–16 моделей ту, для которой получено наибольшее количество отмеченных ответов «да» или «нет» с учетом степени их важности (с наибольшим количеством отмеченных ответов в верхней части приоритетных таблиц). Выбранная модель жизненного цикла является наиболее приемлемой для анализируемого проекта. Т а б л и ц а 13 Выбор модели жизненного цикла ИТ-проекта на основе характеристик требований к нему (критерии категории 1)

Каскадная

V-образная

RAD

Инкрементная

Быстрого прототипирования

Эволюционная

Тип модели

1

Являются ли требования к проекту легко определимыми и реализуемыми?

Да

Да

Да

Нет

Нет

Нет

2

Могут ли требования быть сформулированы в начале жизненного цикла проекта?

Да

Да

Да

Да

Нет

Нет

3

Часто ли будут изменяться требования на протяжении жизненного цикла проекта?

Нет

Нет

Нет

Нет

Да

Да

№ п/п

Критерий

8 См.: Берг Д. Б., Зверева О. М., Вишнякова А. Ю. Управление жизненным циклом информационных систем : учеб. пособие. Екатеринбург : Изд-во Урал. ун-та, 2022. 94 с.

67

Окончание

т а б л. 13

Каскадная

V-образная

RAD

Инкрементная

Быстрого прототипирования

Эволюционная

Тип модели

4

Нужно ли демонстрировать требования с целью их определения?

Нет

Нет

Да

Нет

Да

Да

5

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

Нет

Нет

Да

Нет

Да

Да

6

Будут ли требования изменяться или уточняться с ростом сложности системы?

Нет

Нет

Нет

Да

Да

Да

7

Нужно ли реализовать основные требования на ранних этапах разработки проекта?

Нет

Нет

Да

Да

Да

Да

№ п/п

Критерий

Т а б л и ц а 14 Выбор модели жизненного цикла ИТ-проекта на основе характеристик команды его разработчиков (критерии категории 2)

Каскадная

V-образная

RAD

Инкрементная

Быстрого прототипирования

Эволюционная

Тип модели

1

Являются ли проблемы предметной области проекта новыми для большинства разработчиков?

Нет

Нет

Нет

Нет

Да

Да

2

Являются ли инструментальные средства, используемые в проекте, новыми для большинства разработчиков?

Да

Да

Нет

Нет

Нет

Да

3

Изменяются ли роли участников проекта на протяжении его жизненного цикла?

Нет

Нет

Нет

Да

Да

Да

№ п/п

Критерий

68

Окончание

т а б л. 14

Каскадная

V-образная

RAD

Инкрементная

Быстрого прототипирования

Эволюционная

Тип модели

4

Является ли структура процесса разработки более значимой для разработчиков, чем его гибкость?

Да

Да

Нет

Да

Нет

Нет

5

Важна ли легкость распределения человеческих ресурсов проекта?

Да

Да

Да

Да

Нет

Нет

6

Приемлет ли команда разработчиков оценки, проверки, стадии разработки?

Да

Да

Нет

Да

Да

Да

№ п/п

Критерий

Т а б л и ц а 15 Выбор модели жизненного цикла ИТ-проекта на основе характеристик его пользователей (критерии категории 3)

Каскадная

V-образная

RAD

Инкрементная

Быстрого прототипирования

Эволюционная

Тип модели

1

Будет ли присутствие пользователей ограничено в жизненном цикле разработки?

Да

Да

Нет

Да

Нет

Да

2

Будут ли пользователи оценивать текущее состояние системы в процессе ее разработки?

Нет

Нет

Нет

Да

Да

Да

3

Будут ли польз ователи вовлечены во все фазы жизненного цикла разработки?

Нет

Нет

Да

Нет

Да

Нет

4

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

Нет

Нет

Нет

Нет

Да

Да

№ п/п

Критерий

69

Т а б л и ц а 16 Выбор модели жизненного цикла ИТ-проекта на основе характеристик его типов и рисков (критерии категории 4)

Каскадная

V-образная

RAD

Инкрементная

Быстрого прототипирования

Эволюционная

Тип модели

1

Разрабатывается ли в проекте продукт нового для организации направления?

Нет

Нет

Нет

Да

Да

Да

2

Будет ли проект являться расширением существующей системы?

Да

Да

Да

Да

Нет

Нет

3

Будет ли проект крупно- или среднемасштабным?

Нет

Нет

Нет

Да

Да

Да

4

Ожидается ли длительная эксплуатация продукта?

Да

Да

Нет

Да

Нет

Да

5

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

Нет

Да

Нет

Да

Нет

Да

6

Предполагается ли эволюция продукта проекта в течение его жизненного цикла?

Нет

Нет

Нет

Да

Да

Да

7

Велика ли вероятность изменения системы (продукта) на этапе сопровождения?

Нет

Нет

Нет

Да

Да

Да

8

Является ли график сжатым?

Нет

Нет

Да

Да

Да

Да

9

Предполагается ли повторное использование компонентов?

Нет

Нет

Да

Да

Да

Да

10 Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)?

Нет

Нет

Нет

Нет

Да

Да

№ п/п

Критерий

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

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

Общая модель информационной системы Согласно общей теории систем любая система сводится к составляющим, указанным на рис. 16. Внешняя среда

Вход

Выход Процессы преобразования

Обратная связь Рис. 16. Общая модель информационной системы

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

Вводвывод

Наше решение Вв в ы од во д

Пользователи

Рис. 17. Границы информационной системы 71

Другие системы

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

Модель информационных потоков Любая информационная система состоит из информационных потоков, которые обеспечивают связь (интерфейс) между подсистемами (компонентами) ИС. Как правило, данные связи создаются с помощью различных технологий исходя из специфики самих подсистем (компонентов). Из числа подсистем, часто применяемых в информационных системах, можно выделить следующие: – алгоритмические подсистемы с условными и циклическими операторами; – подсистемы на основе методов интеллектуального анализа данных (Data mining); – подсистемы больших данных (Big data); – подсистемы, основанные на параллельных и асинхронных вычислениях; – подсистемы обработки данных датчиков и внешних сигналов и т. д. На сегодня не существует единого стандарта, определяющего, какие именно подсистемы должны входить в разрабатываемую информационную систему, что объясняется как экспоненциальным ростом количества информационных технологий, так и их интенсивным развитием.

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

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

1.4. Практический пример разработки функционального прототипа Для того чтобы наглядно рассмотреть общий функционал ГИС «Очаги туберкулеза», был построен полный алгоритм работы данного программного обеспечения (рис. 18–20). Алгоритм изображен в соответствии с ГОСТ 19.701-90 «Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения» – это стандарт комитета СССР о вычислительной технике и информатике 1990 года (переиздан в 2010 году). Данный стандарт разработан методом прямого применения международного стандарта ISO 5807-851 «Обработка информации. Символы и условные обозначения блок-схем, данных, программ и систем, схем программных сетей и системных ресурсов». Для реализации проекта разработки геоинформационной онлайн-системы «Очаги туберкулеза» будет использована итерационная модель разработки ГИС. Требования к системе будут меняться в ходе ее пилотной реализации. На втором этапе масштабирования ГИС на другие субъекты РФ понадобится каскадная модель, если все требования после выполнения пилотного проекта будут утверждены. Для реализации проекта была построена модель информационных потоков ГИС (рис. 21). Веб-интерфейс служит для отображения данных медицинской статистики, которые поставляются из консолидированной базы данных медицинских показателей. СУБД – консолидированная база данных медицинских показателей, собираемых системой со внешних источников. 73

Начало Запуск информационной системы, вывод описания региона и легенды ГИС

Описание региона и легенда ГИС

1 Использовать кнопку «Эпидемиологическая обстановка»?

нет

Использовать кнопку «Режим градации ТБО»?

нет

Использовать кнопку «Добавление очага»?

А1

А2

А3

Работа интерфейса «Эпидемиологическая обстановка»

Работа интерфейса «Режим градации ТБО»

Работа электронной формы ввода данных по очагам

Выбрать на отдельный район карты? А4 Работа интерфейса «Районная эпидемиологическая обстановка» Использовать кнопку «Контроль выполнения мероприятий?» А5 Работа интерфейса «Контроль мероприятий» 1 Конец

Рис. 18. Блок-схема запуска геоинформационной системы 74

Начало А1

Начало А2

Открывается интерфейс «Эпидемиологическая обстановка»

Открывается интерфейс «Режим градации ТБО»

Вывод карты и раскраски районов карты в соответствии со шкалой плотности очагов

Карта региона

Вывод карты и раскраски районов карты в соответствии с выбранной группой заболеваний

Карта региона

Формирование и вывод таблиц со статистическими данными по региону

Статистические данные по региону

Формирование и вывод таблиц с данными по конкретной группе заболеваний

Статистические данные по региону

Курсор мыши наведен на один из районов карты?

Курсор мыши наведен на один из районов карты?

да Остальные районы раскрашиваются в темно-синий нейтральный цвет

да Остальные районы раскрашиваются в темно-синий нейтральный цвет

Вывод названия выбранного района

Название района

Вывод таблицы с общими данными по району, на который наведен курсор

Обычные данные по региону

В таблице подсвечивается строка с данными по региону, на который наведен курсор мыши

нет

нет

Конец А1

Конец А2

Рис. 19. Блок-схема работы интерфейсов мониторинга геоинформационной системы 75

Начало А4

Начало А5

Открывается интерфейс «Электронная форма ввода данных по очагам»

Открывается интерфейс «Контроль выполнения мероприятий»

Выводится форма для добавления нового очага

Использовать кнопку «Добавить»?

Вывод таблицы с населенными пунктами и количеством очагов

Форма ввода по очагам

нет

Список населенных пунктов, количество очагов

Выбрать строчку с одним из населенных пунктов?

да Запись и добавление информации об очаге в базу данных

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

Список адресованных очагов

нет

Конец А1

нет

Выбрать строчку с одним из адресов населенного пункта?

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

Конец А5

Рис. 20. Алгоритм работы интерфейса ввода данных и контроля мероприятий геоинформационной системы

76

Список мероприятий по адресу

Централизованная база данных

Веб-интерфейс ГИС «Очаги туберкулеза». Медицинские показатели и картографическая информация

Данные ПО 1С: Медицина

СУБД

Консолидированная база данных медицинских показателей

Дополнительный интерфейс для ввода данных Клиентский интерфейс ввода информации по отдельному району

Рис. 21. Модель информационных потоков ГИС «Очаги туберкулеза»

Централизованная база данных – основной внешний источник данных информационной системы, реализованный на основе программного обеспечения 1С: Медицина. Дополнительный интерфейс для ввода данных разрабатывается при необходимости ручного ввода данных участковыми врачами тех медицинских учреждений, где программное обеспечение 1С: Медицина еще не используется. Далее на основе выявленных ранее требований был разработан фукциональный прототип ГИС и отрисованы эскизы интерфейсов на примере Тюменской области. Первый интерфейс ГИС «Очаги туберкулеза» – «Эпидемиологическая обстановка» (рис. 22) позволит медицинскому работнику увидеть и оценить ситуацию с распространением туберкулеза в интересующей его области Российской Федерации в целом. Здесь будет отражена вся необходимая для этого информация: после выбора области пользователь может получить данные о количестве в ней населенных пунктов, численности и плотности населения, о количестве очагов заболевания в целом и отдельно по каждой группе. Районы на карте области будут раскрашены в соответствии со шкалой плотности очагов, которая представлена в левой части интерфейса, что позволит специалисту быстро визуально определить районы с наиболее тяжелой обстановкой и обратить на них повышенное внимание медицинских и социальных служб. Полный функционал интерфейса «Эпидемиологическая обстановка» (рис. 23) будет раскрываться при наведении курсора мыши на любой из районов выбранной области, после чего медицинский работник получит развернутую информацию, относящуюся исключительно к выбранному 77

78

–

–

–

–

–

–

–

–

–

–

–

–

Ре жим град ации ТБО

Рис. 22. Эскиз интерфейса «Эпидемиологическая обстановка» на примере Тюменской области

Эпиде мио логичес кая об становка

–

–

–

–

– 2

79

–

–

–

–

–

–

–

–

–

–

–

–

–

Ре жим град ации ТБО

Рис. 23. Эскиз интерфейса «Эпидемиологическая обстановка» на примере Уватского района Тюменской области

Эпиде мио логичес кая об становка

–

–

–

–

– 2

району (показатель эпидемиологической напряженности, количество населенных пунктов, численность населения, общее количество очагов, таблица с количеством очагов по каждой группе и процентное отклонение от среднего показателя по области). При этом во время работы специалиста с отдельным районом остальные районы будут окрашены в нейтральный цвет, чтобы не отвлекать пользователя от рассмотрения конкретной ситуации. Второй интерфейс ГИС «Очаги туберкулеза» – «Режим градации туберкулезных очагов» (рис. 24) должен предоставлять медицинскому работнику возможность оценить ситуацию с распространением туберкулеза по конкретной группе данного заболевания. Для этого в нижней части интерфейса будут расположены 5 кнопок, каждая из которых позволяет получить информацию об определенной группе туберкулеза. При нажатии на любую из этих кнопок карта полностью перекрашивается в соответствии со шкалой плотности очагов для выбранной группы, а в правой части интерфейса появляется таблица с информацией только по очагам соответствующей группы заболевания. В этой таблице содержится список всех районов с отражением для каждого из них количества очагов туберкулеза данной группы, а также приводится показатель эпидемиологической напряженности. Третий интерфейс ГИС «Очаги туберкулеза» – «Районная эпидемиологическая обстановка» (рис. 25). Доступ к нему должен открываться при наведении курсора на один из районов области при работе в первом или втором интерфейсе информационной системы. На следующем этапе должна появиться увеличенная версия карты выбранного района с отмеченными на ней населенными пунктами, которые раскрашены в соответствии с расположенной в левой части экрана шкалой плотности в них очагов. Работая с данным интерфейсом, пользователь сможет детальнее изучить ситуацию с распространением туберкулеза по конкретному интересующему его району, для этого здесь будет представлена вся необходимая информация (численность населения, количество очагов и показатель эпидемиологической напряженности). Помимо этого для каждой группы заболевания будет представлена шкала, отражающая динамику выполнения мероприятий по противодействию распространению туберкулеза данной группы в выбранном районе. Также функционал интерфейса «Районная эпидемиологическая обстановка» (рис. 26) позволит специалисту при наведении курсора на любой из населенных пунктов узнать его название и получить основную информацию о количестве очагов туберкулеза и динамике выполнения мероприятий по противодействию распространению данной патологии. Заключительный интерфейс ГИС «Очаги туберкулеза» – «Контроль выполнения мероприятий» (рис. 27). Как следует из названия, он будет использоваться для того, чтобы специалисты сферы здравоохранения могли 80

81

–

–

–

–

–

–

–

–

–

–

–

–

Ре жим град ации ТБО

Рис. 24. Эскиз интерфейса «Режим градации туберкулезных очагов»

Эпиде мио логичес кая об становка

82

–

–

–

–

–

–

–

–

–

–

–

–

Эпиде мио логичес кая об становка

Ко нтроль выпол нения ме ро прият ий

Рис. 25. Эскиз интерфейса «Районная эпидемиологическая обстановка» на примере Ярковского района Тюменской области

Тюменская облас ть

83

–

–

–

–

–

–

–

–

–

–

–

–

Эпиде мио логичес кая об становка

Ко нтроль выпол нения ме ро прият ий

–

–

–

–

–

Рис. 26. Эскиз интерфейса «Районная эпидемиологическая обстановка» на примере выбора населенного пункта Иевлево

Тюменская облас ть

–

84

,

в срок мероприятия

Рис. 27. Эскиз интерфейса «Контроль выполнения мероприятий»

населенных пунктов

Эпиде мио логичес кая об становка

85

Рис. 28. Эскиз полного функционала интерфейса «Контроль выполнения мероприятий»

,

в срок мероприятия

населенных пунктов

Эпиде мио логичес кая об становка

назначать и проведение мероприятий по противодействию распространению туберкулеза для определенного района Российской Федерации, и контролировать их выполнение. С этой целью здесь будет максимально удобно визуализирована вся необходимая информация. При запуске интерфейса перед пользователем откроется список населенных пунктов выбранного района с числом очагов по каждому из них. При этом данные в строках отобразят динамику выполнения мероприятий в конкретном населенном пункте согласно легенде, которая представлена в нижней части интерфейса. Помимо этого справа будет помещена уменьшенная версия карты выбранного района и отражена общая динамика выполнения мероприятий по противодействию распространению туберкулеза в процентном соотношении. Полный функционал интерфейса «Контроль выполнения мероприятий» (рис. 28) будет раскрыт при нажатии на строку с указанием интересующего населенного пункта, после чего появится список очагов по конкретным адресам, а при активации одного из приведенных адресов появится таблица, содержащая информацию о выполнении мероприятий по данному адресу (название мероприятия, дата его назначения и статус выполнения; при необходимости можно узнать и причину невыполнения мероприятия). Таким образом, с помощью данного интерфейса пользователь в наглядном виде получит всю информацию о выполнении мероприятий по противодействию распространению туберкулеза в интересующем районе включая конкретные даты и адреса. Итак, полная и наглядная визуализация данных в ГИС «Очаги туберкулеза» позволит специалистам сферы здравоохранения осуществлять пространственный анализ заболеваемости населения туберкулезом всех групп на различных масштабных уровнях, от областей до конкретных населенных пунктов. Благодаря ГИС ОТБ медицинские работники в максимально понятном и удобном виде получат всю необходимую информацию для своевременного принятия эффективных мер по противодействию туберкулезу посредством грамотного распределения ресурсов, назначения противотуберкулезных мероприятий и контроля их выполнения, а также для усовершенствования организационной политики медицинских и социальных служб.

86

2. ПОДХОД К РАЗРАБОТКЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1. Разработка информационной системы Классификация языков программирования Существующие языки программирования классифицируют по четырем основным группам: процедурные, декларативные, объектно-ориентированные и сетевые. Процедурные языки программирования. При использовании процедурных языков программа отделена от данных и состоит из последовательности команд, обрабатывающих эти данные. Данные, как правило, хранятся в виде переменных, и весь процесс вычисления сводится к изменению их содержимого. Декларативные языки программирования. Это языки объявлений и построения структур. К декларативным относятся функциональные и логические языки программирования. В этих языках алгоритмические действия не производятся явно, то есть алгоритм строится самой программой, а не задается программистом. В декларативных языках задается и производится построение какой-либо структуры или системы, то есть декларируются (объявляются) какие-то свойства создаваемого объекта. Эти языки получили широкое применение в системах автоматизированного проектирования (САПР), в так называемых CAD-пакетах, в моделировании, в системах искусственного интеллекта. Объектно-ориентированные языки программирования. В этих языках переменные и функции группируются в так называемые классы (шаблоны), благодаря чему достигается более высокий уровень структуризации программы. Объекты, порожденные от классов, вызывают методы (функции или процедуры) друг друга и меняют таким образом состояние свойств (переменных). С формально-математической стороны объектно-ориентированный способ написания программ базируется на процедурной модели программирования, но с содержательной стороны объектно-ориентированное программирование основано не на функции, а на объекте как на целостной системе, имеющей стандартный автоматический межобъектный интерфейс. Сетевые языки программирования. Предназначены для организации взаимодействия удаленных компьютеров в интенсивном интерактивном режиме, поэтому они построены на принципах интерпретации, то есть построчной, интерактивной обработки строк программного кода, описываю87

щего некоторый сценарий (скрипт) сетевого взаимодействия компьютеров. Часто сетевые языки программирования называются скриптовыми языками, хотя скриптовые языки не обязательно являются сетевыми. В качестве примера можно привести пакетные командные языки различных операционных сред. Единого языка программирования, универсального для всех приложений, не существует. Сейчас для многих стандартных пользовательских приложений используется комбинация SQL и C# для серверной программной части и HTML/CSS/JavaScript для создания интерфейса пользователей. Так, например, для работы с базами данных в C# и .NET применяется технология ADO.NET, а также Entity Framework – технология ORM, которая позволяет сопоставлять сущности C# с таблицами в базе данных, что упрощает работу. Для других языков программирования используются аналогичные интерфейсы (адаптеры), обеспечивающие связь с базой данных. Но все чаще программисты обращаются к альтернативным подходам, предусматривающим файловое хранение данных, таким как CSV, JSON, XML. Это обусловлено тем, что современные накопители SSD NVME имеют в разы более быструю скорость по сравнению с HDD-накопителями, поэтому для реализации хранилища данных все большее распространение получает текстовый формат. В современных ERP-системах используются в основном собственные языки программирования, в связи с чем поддерживающие их специалисты должны уметь работать не только с формами / интерфейсом пользователей, но и, в первую очередь, со структурой системы и безопасно вносить необходимые изменения в код. Требуется знание SAP, ABAP, Oracle, PL/SQL, Java, Microsoft Dynamics AX, среды разработки MorphX с языками программирования X+, Microsoft Dynamics NAV, графической среды разработки C/SIDE с языком программирования C/AL. Пользовательский графический интерфейс и программный алгоритм связываются с помощью различных библиотек и фреймворков, для того же C# это могут быть WindowsForms или WPF, для языка Python библиотека Qt5 и т. д. Надо отметить, что в современных реалиях предпочтение для реализации графического интерфейса отдается WEB. Веб-интерфейсы обладают кроссплатформенностью и универсальностью благодаря популярности технологий HTML, CSS, JavaScript. Код программы может являться самодостаточным способом настройки системы либо же дополняться ее «конфигуратором» или «конструктором». Разница между ними заключается в возможностях внесения изменений (бизнес-логика и правила работы приложения требуют обычно большего и более сложного объема работы, нежели просто добавление нового поля). Для простых же функций используются в основном стандартные конфигураторы сис88

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

CASE-средства. Общая характеристика Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл программного обеспечения. CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации, что предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. В разряд CASE-средств попадают как относительно дешевые информационные системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных продуктов насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами. Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла программного обеспечения и обладающее следующими характеристиками: – мощные графические инструменты для описания и документирования информационных систем, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности; – интеграция отдельных компонентов CASE-средств, обеспечивающая управляемость процессом разработки ИС; – использование специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл программного обеспечения) содержит следующие компоненты; – репозиторий, являющийся основой CASE-средства (он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхрони89

зацию поступления информации от различных разработчиков при групповой их деятельности, контроль метаданных на полноту и непротиворечивость); – графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели информационной системы; – средства разработки приложений (включая языки 4GL и генераторы кодов); – средства конфигурационного управления; – средства документирования; – средства тестирования; – средства управления проектом; – средства реинжиниринга. Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла информационных систем (toolkit), и полностью интегрированные средства, поддерживающие весь жизненный цикл ИС и связанные общим репозиторием. Помимо этого CASE-средства можно классифицировать по следующим признакам: – по применяемым методологиям и моделям систем и баз данных; – степени интегрированности с системой управления базами данных; – доступным платформам.

2.2. Разработка информационных потоков для информационной системы Рассмотрим пример разработки информационной системы. Первоначальным ее этапом выступает разработка REST API JSON. Накладываемые ограничения определяют функционирование сервера в том, как он может обрабатывать запросы клиентов и отвечать на них. Действуя в рамках этих ограничений, система приобретает такие желательные свойства, как производительность, масштабируемость, простота, способность к изменениям, переносимость, отслеживаемость и надежность. Физическая модель базы данных приведена на рис. 29. Каждая таблица являет собой сущность, описанную в техническом задании (subjects, events, 90

hashes и users). Наибольший интерес здесь представляют таблицы hashes и users. hashes

Рис. 29. Физическая модель базы данных

Таблица hashes содержит следующие поля: – еmail (сопоставляемый email, на который отправляются электронные письма; служит основой для формирования хэша и идентификации); – h_time (время активности хэш-ссылки, отправленной на email; формируется путем добавления к времени отправки запроса временнóй константы; если текущее время превышает h_time, соответствующая запись удаляется из таблицы hashes, и ссылка становится неактивной); – hash (непосредственно хэш-ссылка); – type (поле, идентифицирующее тип отправляемого запроса для рендера шаблонов, – регистрация, смена пароля, смена email и т. д.). В таблице users помимо стандартных для подобных сущностей полей (u_name, password, email, role) используются дополнительные поля: notification (флаг, содержащий в себе информацию о том, включены ли пользователем оповещения); counter (количество новых событий; если оповещения отключены, значение равно 0); active (флаг, отмечающий, активирована ли учетная запись). 91

В ходе работы для взаимодействия с базой данных и облаком PS Cloud было создано API, соответствующее всем перечисленным выше требованиям. Ниже представлены примеры маршрутов, обслуживаемых API. / --------------- EVENTS > app.get('/events', loadUser, async function (req, res) {…}) > app.get("/events/data", loadUser, async function (req, res) {…}); > app.post("/events/delete", async function (req, res) {…}); > app.post("/events/search", loadUser, async function (req, res) {…}); > app.post('/events', async function (req, res) {…}); // --------------- EVENTS // --------------- USERS > app.get('/users', loadUser, async function (req, res) {…}); > app.get('/users/edit', loadUser, async function (req, res) {…}); > app.post('/users/edit', loadUser, async function (req, res) {…}); > app.get("/users/data", loadUser, async function (req, res) {…}); > app.post("/users/update", loadUser, async function (req, res) {…}); > app.get("/users/delete", loadUser, async function (req, res) {…}); // --------------- USERS

Далее: request.post('htttp://127.0.0.1:3000/events', {useralias: 'testuser@factory', time: Date.now(), thermo: 38, img: fs.readFileSync('img.png', 'base64')}, error, res) => {if (error) {console.error(error) return} console.log(res.body.status, res.body.mess)});

Разработка интерфейсной части Разработка интерфейса проведена преимущественно при помощи стандартных средств HTML/CSS/JS, фреймворк Bootstrap не применялся. Для реализации механизма шаблонизации использовался Handlebars (Node.js совместно с Express.js). Для разработки серверной части в качестве платформы для написания сервера используется Node.js в связке с библиотекой Express.js. Node или Node.js – программная платформа, основанная на движке V8 (транслирующем JavaScript в машинный код) и превращающая JavaScript из узкоспециализированного языка в язык общего назначения. Node.js позволяет JavaScript взаимодействовать с устройствами ввода-вывода через свой API (написанный на C++), подключать другие внешние библиотеки, написанные на разных языках, обеспечивая вызовы к ним из JavaScript-кода. Применяется Node.js преимущественно на сервере, выполняя роль вебсервера. 92

Express.js – это минималистичный и гибкий веб-фреймворк для приложений Node.js, предоставляющий обширный набор функций для мобильных приложений и веб-приложений. Все используемые в работе библиотеки представлены ниже. const express = require("express"); var config = require('./config. json'); const expressHbs = require("express-handlebars") const hbs = require("hbs"); const app = express(); const jsonParser = express. json(); const session = require('express-session') const bodyParser = require("body-parser") const urlencodedParser = bodyParser.urlencoded({ limit: '128mb', extended: true }); const sqlite = require("sqlite"); const path = require('path'); const redisStorage = require('connect-redis') (session); const redis = require('redis'); const client = redis.createClient(); const ws = require('ws'); const http = require('http'); const fs = require('fs'); const crypto = require('crypto'); const nodemailer = require("nodemailer");

Далее приводится фрагмент кода обработчика маршрута, отвечающего за добавление события, полученного от сервера, в промежуточную базу данных. app.post('/events', async function (req, res) { let db = await sqlite.open('dev'); let useralias = req.body.useralias; let time = req.body.time; let thermos = req.body/thermos; let img = Buffer.from(req.body.img, 'base64'); fs.mkdirSync('photos' , { recursive: true }); fs.writeFileSync('photos'/${useralias}_${time{.${req.body.img_ext}', img); let img_name = 'pho-tos/${useralias}_${tine}.${req.body.img_ext}' var event = "" var tmp = [] if (Number(thermo) >= event = "high temp"; } else { event = "event" }

config.thermo)

{

wss.clients.forEach(function each(client) { if (client.readyState === ws.OPEN) { client.send(JSON.stringify({ 'event type': "event" } });

93

}));

let t = await db.get('SELECT * FROM subjects WHERE s_useralias ?', useralias); let prev = await db.all("SELECT e_id FROM events WHERE =s_id = ? AND time = ? AND termo = ? ", [t.s_id, time, thermo]); console.1og(prev); if (prev.length > 0) { res.json({ 'status': '500', 'mess': 'Failes to insert event (dublicate)' }); } else { =

try { let s = await db.run('INSERT INTO events (s_id, time, termo, e_name, img) VALUES (?, ?, ?, ?, ?)', [t.s_id, time, thermo, event, img_name]); res.json({ 'status': '500', 'mess': 'Succesfully created event ${s.stmt.lastID) with user ${t.s_name)' }); } catch (error) { console.error(error); res.json({ 'status': '500', 'mess': 'Failed to insert event' }); } } let temp = await db.al1('SELECT * FROM users'); for (let i= 0; i < temp.length; i++) { let s = await db.run('UPDATE users SET counter = counter +1 WHERE u_id = ? ', [temp[i].u_id]); } db.close(); });

Обеспечение безопасности приложения Для того чтобы приложение было достаточно безопасным, требуется наличие обеспечивающих это инструментов. Рассмотрим фрагмент кода для отправки запроса на регистрацию нового пользователя. Как можно заметить, в коде задана проверка на наличие используемого email в базе, пользователь изначально создается со статусом «неактивен», и до подтверждения почтового адреса посредством пришедшего на указанный email письма вход в систему будет невозможен. Ссылка подтверждения генерируется при помощи модуля криптографии Crypto и является уникальной в пределах системы, а хэш хранится в базе всего сутки, в течение которых возможно подтверждение. app.post('/events', async function (req, let db = await sqlite.open('dev'); let username = req.body. username; let password = req.body.newPassF5; let email = req.body.email;

94

res)

{

=

console.1og(req.body); let tmp = await db.get ?', email);

('SELECT

*

FROM

users

WHERE

email

if (tmp) { res.render('register', { message: 'Почта ${email} уже используется. Используйте другую почту или восстановите пароль по следующей ссылке', email: email }) } else { try { let t = await db.run('INSERT INTO users (username, password, email) VALUES(?,?,?)', [username, password, email]); // Запись в БД с active : 0 console.1og(t); let type = 'reg'; let time = String(Date.now() + 3600000 * 24); // Ссылка на регистрацию активна сутки v ar h as h = c ry pt o. c re at eH as h ( 's ha 25 6 " ). up da t e( em ai l) . update(time).digest('hex'); let s = = await db.run(' INSERT INTO hashes (email, time, hash, type) VAL-UES( ? , ? , ? , ?) ' , [email, time, String(hash), type])}; db.close(); console.log(s); try { mailer(email, hash, username) } catch (error) { console.error(error); res.json({ 'status': '500', 'mess': ' Failed to send email to ${email} ' }); } res.render('register', { message: 'На почту ${email} было отправлено письмо для продолжения регистрации. Пожалуйста, проверьте почтовый ящик.', email: email }) } catch (error) { console.error(error); res. json({ 'status': '500", 'mess': ' Failed to register new user ' }); } } });

95

Также в системе предусмотрена middleware-функция loadUser, представленная в коде и являющаяся промежуточным обработчиком при обращении к любому ресурсу приложения, кроме страниц регистрации, авторизации и запросов от внешних API. Как можно увидеть из кода функции, она проверяет, что в сессии присутствует идентификатор пользователя, и если его нет, то навигация по приложению запрещается, а пользователь перенаправляется на страницу авторизации. Время жизни сессии ограничено одним часом. Если идентификатор сессии присутствует, то будет выполняться следующая за loadUser функция, то есть непосредственно функция обработчика маршрута.

'

async function loadUser(req, res, next) { if (req.session.user_id) { let db = await sqlite.open('dev'); let s = await db.get('SELECT * FROM users , [req.session.user_id]); console. 1og(s) if (s) { next (); }else { req.session.destroy(); res.clearCookie('role'); res.clearCookie('notification'); res.clearCookie('counter'); res.redirect("/login"); } } else { req.session.destroy(); res.clearCookie('role'); res.clearCookie('notification'); res.clearCookie('counter'); res.redirect("/login"); } }

WHERE

u_id

=

?

Для реализации системы уведомлений используются сессии. Условно работу с сессиями можно разделить на две части: клиентскую и серверную. Между сервером и клиентом существует соединение, поддерживаемое комбинацией функций ping-pong. Когда на сервер приходит оповещение о событии, он рассылает каждому подключенному клиенту сообщение об этом. Все активные клиенты принимают сообщение, интерпретируют его и выполняют некоторые действия, например выводят уведомления в виде всплывающих окон и счетчика. Фрагменты кода для клиента и сервера представлены ниже.

96

Фрагмент кода для клиента: client.onmessage

=

function

incoming(data)

{

cont = document .getElementById("al"); cont.style.display = "block"; var element = document getElementById("elem"); var

tmp

=

JSON.parse(data.data);

if (tmp.event_type == 'high_temp') { let dataHtml = ' '; dataHtml += '

Обнаружена температура' '+ tmp.thermo +" y "+ tmp.user + "

"; element.innerHTML += dataHtml; } if (tmp.event_type == "event") { new_events = new_events + 1; elem.innertHTML = '+ ${getGlobalVar('new')}'; saveGlobalVar('new', new_events); } reload(); } function deleteElement(element) { $(element).parent().parent() .remove(); } let

el

=

document.getElementById("al");

if (!el.children) { el.style.display = "none"; } } else { $("new").css("display", "none"); } $(document).ready(function () { $('.show').click(function () { var details = $(".details"); $(this) find(details).s1ideToggle(500); }); });

Фрагмент кода для сервера: function heartbeat() { this.isAlive = true; } const

wss

=

new

ws.Server({

97

server

});

wss.on('connection', async function connection(ws) { let db = await sqlite.open('dev'); let data = await db.all('SELECT * FROM events WHERE time BETWEEN ? AND ?', [Date.now() - 900000, Date.now()]);

?

let tmp = [] for (let i = 0; i < data.length; ++i) { if (data[i].termo >= config.thermo) { let t = {} let s = await db.get('SELECT * FROM subjects ', data[i].s_id); t['event_type'] = 'high_temp'; t['user'] = s.s_name; t['thermo'] = data[i].termo; let dat = JSON. stringify(t); ws.send(dat); } } db.close();

WHERE

s_id

=

ws.isAlive = true; ws.on('pong', heartbeat); }); const interval = setInterval(function ping() { wss.clients.forEach(function each(ws) { if (ws.isAlive === false) return ws.terminate(); ws.isAlive = false; ws. ping(noop); }); }, 30000); wss.on('close', function close() clearInterval (interval); });

{

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

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

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

Методика тестирования Широко используемыми методами тестирования являются модульное тестирование, интеграционное тестирование, функциональное тестирование, тестирование системы и приемочное тестирование. Программное обеспечение подвергается этим испытаниям в определенном порядке: 1) модульное тестирование (Unit testing); 2) интеграционное тестирование (Integration testing); 3) функциональное тестирование (Functional testing); 4) системное тестирование (System Testing); 5) приемочное тестирование. Модульное тестирование. В первую очередь проводится модульный тест. Как подсказывает название, это метод испытания на объектном уровне. Отдельные программные компоненты тестируются на наличие ошибок. Для этого тестирования требуется точное знание программы и каждого установленного модуля. Таким образом, модульное тестирование осуществляется программистами, а не тестерами. Для этого создаются тест-коды, позволяющие проверить, ведет ли программное обеспечение себя так, как задумывалось. Интеграционное тестирование. Отдельные модули, которые уже были подвергнуты модульному тестированию, интегрируются друг с другом и проверяются на наличие неисправностей. Такой тип тестирования в первую очередь выявляет ошибки интерфейса. Интеграционное тестирование 99

можно осуществлять с помощью подхода «сверху вниз», следуя архитектурному сооружению системы. Другим подходом является подход «снизу вверх», который осуществляется из нижней части потока управления. Такое тестирование выполняется как вручную, так и автоматизированно с использованием специальных инструментов, таких как Postman, SoapUI, Apache JMeter, TestComplete, Selenium. Пример. Приложение для онлайн-оплаты, которое включает в себя вебинтерфейс, API для обработки платежей и базу данных для хранения информации о платежах. Интеграционное тестирование поможет убедиться в том, что компоненты работают корректно вместе. Один из возможных сценариев тестирования таков: 1) запрос на создание нового платежа отправляется через веб-интерфейс; 2) API для обработки платежей получает запрос и создает новую запись в базе данных; 3) веб-интерфейс получает уведомление о создании нового платежа и отображает его в списке платежей на странице; 4) пользователь проверяет, что новый платеж отображается на странице, и подтверждает его. Функциональное тестирование. Проводится для проверки функциональности приложения. Оно позволяет убедиться в том, что приложение работает корректно и выполняет функции, соответствующие требованиям пользователей и заказчика. Назначение функционального тестирования – проверка отдельных функций и возможностей приложения, а назначение интеграционного тестирования – проверка взаимодействия компонентов системы в целом. Примеры инструментов для автоматизации функционального тестирования: Selenium, TestComplete, Appium, SoapUI, TestNG. Пример. Веб-приложение для онлайн-бронирования номеров в отеле. Функциональное тестирование поможет убедиться в том, что приложение работает корректно и выполняет свои функции. Возможный сценарий тестирования: 1) пользователь открывает веб-страницу приложения и выбирает нужную дату заезда и выезда; 2) приложение отображает свободные номера в отеле на выбранные даты; 3) пользователь выбирает номер и вводит свои данные для бронирования; 4) приложение подтверждает бронирование и отправляет подтверждение на электронную почту пользователя. Дополнительно: End-to-End тестирование (E2E-тестирование). Это тестирование позволяет проверить работу всей системы или приложения с точки зрения пользователя от начала и до конца. 100

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

Основные тесты Существует несколько основных тестов, которые формируют часть режима тестирования программного обеспечения. Эти тесты обычно считаются самодостаточными в поиске ошибок и багов во всей системе. Тестирование методом «черного ящика». Тестирование методом «черного ящика» осуществляется без каких-либо знаний внутренней работы системы. Тестер будет стимулировать программное обеспечение для пользовательской среды, предоставляя различные входы и проверяя сгенерированные выходы. Этот тест также известен как black-box-тестирование, closed-box-тестирование или функциональное тестирование. Тестирование методом «белого ящика». Тестирование методом «белого ящика», в отличие от тестирования методом «черного ящика», учитывает внутреннее функционирование и логику работы кода. Для выполнения этого теста тестер должен знать код, чтобы точно определить ту его часть, где имеются ошибки. Этот тест также известен как white-box-, open-box- или Glassbox-тестирование. 101

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

Нефункциональные тесты Тестирование безопасности. Безопасность приложения является одной из главных задач разработчика. Тестирование безопасности предназначено для проверки конфиденциальности, целостности, аутентификации, доступности и безотказности программного обеспечения. Индивидуальные испытания проводятся в целях предотвращения несанкционированного доступа в программный код. Стресс-тестирование. При стресс-тестировании программное обеспечение подвергается воздействию условий, выходящих за рамки нормальных условий его работы. После достижения критической точки полученные результаты записываются. Этот тест определяет устойчивость всей системы. Тестирование на совместимость. Программное обеспечение проверяется на совместимость с внешними интерфейсами, такими как операционные системы, аппаратные платформы, веб-браузеры и т. д. Данный тест позволяет определить, совместим ли продукт с любой программной платформой. Тестирование эффективности. Как подсказывает название, эта методика тестирования дает возможность проверить объем кода или ресурсов, которые используются программой при выполнении одной операции. Юзабилити-тестирование. Назначение данного теста – проверка удобства и практичности программного обеспечения для пользователей. Легкость, с которой пользователь может получить доступ к устройству, формирует основную точку тестирования. Юзабилити-тестирование включает пять аспектов тестирования: обучаемость, эффективность, удовлетворенность, запоминаемость и ошибки. Нагрузочное тестирование. Проводится для определения максимальной нагрузки, которую может выдержать приложение. В процессе нагрузочного тестирования проверяется производительность приложения и выявляются возможные проблемы в его работе при большой нагрузке. Пример. Необходимо убедиться, что онлайн-магазин продолжает работать корректно, когда к нему обращается большое количество пользователей. 102

2.4. Реализация функционального тестирования приложения Оценка приложения выполняется посредством функционального тестирования в ручном режиме. Выполняющий такое тестирование человек проверяет работу всех функций приложения вручную либо путем взаимодействия с программным обеспечением и API с помощью соответствующего инструментария. В функциональных тестах основное внимание уделяется бизнестребованиям к приложению. Они проверяют только результат некоторого действия и не проверяют промежуточные состояния системы при выполнении этого действия. Основная бизнес-логика приложения проверяется с помощью тест-кейсов, представленных в табл. 17–24. Т а б л и ц а 17 Условия просмотра историй в тест-кейсе № 1 № п/п

Назначение

Сущность

1

Заголовок

Тестирование просмотра историй

2

Роль

Пользователь

3

Предусловие

Открыта страница историй пользователя

Т а б л и ц а 18 Тестирование просмотра историй в тест-кейсе № 1 № п/п

Шаг

Ожидаемый результат

Да

1

Выбрать историю из списка историй

Открылось окно истории со списком глав

+

2

Использовать кнопку «Начать»

Открылся диалог главы

+

3

Использовать кнопку «Далее»

Появилось следующее сообщение диалога

+

4

Использовать кнопку «Закрыть» в левом верхнем углу

Диалог главы закрылся

+

5

Использовать зеленую кнопку «Продолжить»

Открылся диалог главы с сохраненным процессом

+

6

Использовать синюю кнопку «Сброс»

Открылось модальное окно с текстом «Начать сначала историю “ ”?»

+

7

Использовать кнопку «Начать заново»

Открывается диалог главы без прогресса

+

103

Нет

Т а б л и ц а 19 Условия создания историй и глав в тест-кейсе № 2 № п/п

Сущность

Назначение

1

Заголовок

Тестирование создания историй и глав

2

Роль

Автор истории

3

Предусловие

Открыта страница администрирования историй

Т а б л и ц а 20 Тестирование создания историй и глав в тест-кейсе № 2 № п/п

Шаг

Ожидаемый результат

Да

1

Использовать кнопку Add в верхнем правом углу

Открылось модальное окно с формой

+

2

Ввести значение в поле Name

В поле Name отображается введенное имя

+

3

Ввести значение в поле Description

В поле Description отображается введенный текст

+

4

Использовать под заполняемой формой кнопку Save

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

+

5

Найти в списке историю с указанным именем

История найдена

+

6

Использовать кнопку с иконкой «Стрелочка вниз» на блоке созданной истории

Под блоком истории раскрылся пустой список глав

+

7

Использовать кнопку Add посередине списка глав

Открылось модальное окно с формой

+

8

Ввести значение в поле Name

В поле Name отображается введенное имя

+

9

Ввести значение в поле Description

В поле Description отображается введенный текст

+

10

Ввести значение в поле Order

В поле Order отображается введенный текст

+

11

Использовать под заполняемой формой кнопку Save

В левом нижнем углу появляется сообщение, что глава с указанным именем создана, в списке глав появилась глава с указанным именем

+

12

Выбрать название созданной главы

Открылась страница конструктора

+

104

Нет

Т а б л и ц а 21 Условия конструктора историй в тест-кейсе № 3 № п/п

Сущность

Назначение

1

Заголовок

Тестирование конструктора историй

2

Роль

Автор истории

3

Предусловие

Создана новая история, новая глава. Открыта страница конструктора историй

Т а б л и ц а 22 Тестирование конструктора историй в тест-кейсе № 3 № п/п

Шаг

Ожидаемый результат

Да

1

Использовать кнопку Edit на верхней панели

Раскрылась панель инструментов под верхней панелью

+

2

Использовать желтую кнопку «Создание элементов»

Раскрылось окно со списком элементов

+

3

Выбрать элемент BOT

Закрылось окно со списком элементов

+

4

Выбрать поле для размещения элементов

Появился выбра нный элем ент на указанном месте

+

5

Переместить выбранной элемент

Элемент перемещен

+

6

Двойной щелчок на выбранном элементе

Появилась возможность редактировать поля

+

7

Ввести значение в поле Bot name

В поле Bot name отображается введенное имя

+

8

Ввести значение в поле Text

В поле Text отображается введенный текст

+

9

Двойной щелчок в свободном месте на поле для размещения элементов

Сохранились редактируемые поля

+

10

Использовать желтую кнопку «Создание элементов»

Раскрылось окно со списком элементов

+

11

Выбрать элемент Context

Закрылось окно со списком элементов

+

105

Нет

Окончание № п/п

т а б л. 22

Шаг

Ожидаемый результат

Да

12

Выбрать поле для размещения элементов

Появился выбранный элемент на указанном месте

+

13

Выбрать элемент BOT

Появилась голубая рамка вокруг элемента BOT

+

14

Использовать синюю кнопку «Связь»

На кнопке «Связь» поменялась иконка

+

15

Выбрать элемент Context

Появилась стрелка между элементами

+

16

Выбрать на стрелке кнопку «Удалить»

Стрелка удалена

+

17

Выбрать элемент «Рамка»

Появилась голубая рамка вокруг элемента

+

18

Использовать красную кнопку «Удалить»

Элемент удален

+

Нет

Т а б л и ц а 23 Условия прохождения диалога в тест-кейсе № 4 № п/п

Сущность

Назначение

1

Заголовок

Тестирование прохождения диалога

2

Роль

Пользователь

3

Предусловие

Открыта глава тестовой истории. Наличие подключенного микрофона

Т а б л и ц а 24 Тестирование прохождения диалога в тест-кейсе № 4 № п/п

Шаг

Ожидаемый результат

Да

1

Использовать кнопку «Продолжить»

Появился следующий элемент диалога

+

2

Использовать кнопку «Воспроизведение» рядом с вопросом

Воспроизвелся вопрос

+

106

Нет

Окончание № п/п

Шаг

т а б л. 24

Ожидаемый результат

Да

3

Удерживать кнопку микрофона

Появилась анимация кнопки микрофона

+

4

Прочитать текст подсказки к вопросу и отпустить кнопку микрофона

Появились информация о качестве ответа и кнопка «Продолжить»

+

5

Использовать кнопку «Продолжить»

Появился следующий элемент диалога

+

6

Удерживать кнопку микрофона

Появилась анимация кнопки микрофона

+

7

Произнести невнятную фразу и отпустить кнопку микрофона

Появилась информация о качестве ответа; кнопка «Продолжить» заблокирована

+

8

Использовать кнопку «Воспроизведение» на нижней панели

Воспроизводится произнесенная фраза

+

9

Удерживать кнопку микрофона

Появилась анимация кнопки микрофона

+

10

Произнести внятную фразу и отпустить кнопку микрофона

Появились информация о качестве ответа и кнопка «Закончить главу»

+

11

Использовать кнопку «Закончить главу»

Открылось окно списка глав истории

+

Нет

Для проверки каждого модуля приложения должно быть составлено несколько функциональных тест-кейсов, выполняющихся в ручном режиме. Тестирование проводится после реализации как отдельной функции, так и всего модуля. На момент завершения спринта должны быть протестированы следующие модули приложения: статистика, словарь, диалоги и конструктор историй. При тестировании самого объемного модуля – модуля диалогов непосредственно после реализации первичного тестирования может быть выявлено довольно много дефектов и несоответствий бизнес-требованиям. Это влечет за собой работу над ошибками и незначительное исправление спецификаций, но в итоге к концу спринта все недочеты должны быть устранены и данный модуль должен успешно пройти тестирование. 107

Функциональное тестирование обеспечивает контроль соответствия разрабатываемого приложения бизнес-требованиям. Несмотря на то, что проверить все характеристики приложения только лишь с помощью функционального тестирования невозможно, для этапа MVP его достаточно.

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

Управление жизненным циклом корпоративной информации Ключевая проблема современного бизнеса – образование больших объемов корпоративных данных. Данные накапливаются быстрее, чем производится их обработка. Для решения этой проблемы применяется концепция управления жизненным циклом информации – Information Lifecycle Management (ILM). Исходя из концепции ILM требуется обеспечение постоянного контроля за возникновением, использованием, хранением и ликвидацией данных. 108

Важнейшими практиками в теории управления жизненным циклом информации являются: – отслеживание динамики ценности данных с течением времени; – разграничение понятий «данные» и «информация». Ценность данных напрямую зависит от их свежести, доступности и безопасности. Со временем и по мере использования данные устаревают, а потому не имеет смысла выделять ресурсы для их хранения. Информация же – это данные, имеющие определенную ценность и смысл для их владельца. Именно поэтому, согласно концепции ILM, приоритет отдается управлению информацией, а не просто данными. Ключом к управлению информацией служит ее семантическая классификация. Для классифицирования применяются следующие инструменты, формируемые на основе требований и архитектуры предприятия: – политика, на основе которой ведется управление хранением информации (действия с классами информации при различных условиях); – целевые показатели уровня сервиса (Service Level Objectives, далее – SLO), которыми должны обеспечиваться конкретные классы информации. На основе концепции ILM производится построение и администрирование комплексных иерархических систем хранения информации – Hierarchical Storage Management (далее – HSM). В таких системах наиболее релевантная информация хранится на быстродоступных и быстродействующих носителях. Неиспользуемые данные спустя заданный период времени после последнего их применения переносятся на более медленные накопители и удаляются с накопителей быстрых. Если пользователь пытается получить доступ к этим данным, они удаляются с медленного накопителя и перезаписываются на накопитель быстродейственный. Так обеспечивается наиболее эффективное использование ресурсов организации. При этом для пользователя разница между накопителями чаще всего не заметна, за исключением небольших задержек. После размещения приложений и информации в иерархической системе хранения в работу организации внедряется применение политик ILM и SLO. Сначала это производится для ключевых приложений, после чего должна образоваться автоматическая система размещения и передачи информации на всех уровнях архитектуры систем хранения данных.

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

когда это необходимо. Комплект специализированного оборудования и программного обеспечения, предназначенного для хранения и передачи больших массивов информации, называется системой хранения данных (СХД). Основной задачей системы хранения данных является организация содержания информации на дисковых площадках с оптимальным распределением аппаратных ресурсов. В системы хранения данных входят следующие элементы: – устройства хранения (дисковые массивы); – инфраструктура доступа к устройствам хранения; – подсистема резервного копирования / архивирования данных; – программное обеспечение управления хранением; – система мониторинга и управления. Рассмотрим вариацию структурной схемы системы хранения данных. В нее могут входить два контроллера дисков, включающие процессоры и интерфейсы для коммутации с жесткими дисками (Fibre Channel Arbitrated Loop, далее – FC-AL) и внешними портами. Кэш-память зеркалируется для предотвращения потери данных при выходе из строя одного из модулей. Внешний интерфейс на схеме работает с протоколом транспортного уровня Fibre Channel. Диски в системе делятся на группы и объединяются в массивы Redundant Array of Independent Disks (далее – RAID-массивы). Получившееся дисковое поле делится на логические блоки (Logical Unit Number, далее – LUN), которые хосты, получающие к ним доступ, видят как локальные жесткие диски. Перечислим ключевые требования к системам хранения данных: – надежность и отказоустойчивость (должно предусматриваться резервирование всех компонентов); – обязательное наличие системы контроля и оповещения о проблемах; – доступность данных (сохранение целостности данных обеспечено технологией RAID, системой создания полных и мгновенных копий данных, их реплицированием на удаленную СХД и др., а также возможностью добавления аппаратуры и программного обеспечения в горячем режиме без остановки комплекса); – наличие средств управления и контроля (управление осуществляется через веб-интерфейс или командную строку, предусмотрены функции мониторинга, диагностики и оповещения администратора о неполадках); – производительность системы (определяется числом и типом накопителей, объемом кэш-памяти, вычислительной мощностью процессорной подсистемы, числом и типом внутренних и внешних интерфейсов, а также возможностями гибкой настройки и конфигурирования); 110

– масштабируемость (должна быть предусмотрена возможность наращивания числа жестких дисков, объема кэш-памяти, аппаратной модернизации и расширения функционала с помощью специального программного обеспечения без потерь функциональности, что позволяет экономить и гибко подходить к проектированию ИТ-инфраструктуры). В современных системах хранения информации цепочки связей между приложениями и мощностями носителя, содержащего эту информацию, имеют следующие звенья: – создание RAID-массивов; – обработка метаданных, позволяющих интерпретировать двоичные данные в виде файлов и записей; – сервисы по предоставлению данных приложению. Обратимся теперь к топологиям построения систем хранения данных и рассмотрим их специфику. Система хранения данных топологии DAS (Direct Attached Storage) подключается напрямую к серверу (как правило, через интерфейс по протоколу Serial Attached Small Computer System Interface, далее – SAS) и является расширением его дисковой системы хранения. Данная топология СХД представляет собой дисковую корзину с жесткими дисками, вынесенную за пределы сервера. Чтобы получить данные, клиент обращается к серверу через сеть. На рис. 30 указаны достоинства и недостатки использования DAS-топологии и сферы ее применения. Система хранения данных топологии NAS (Network Attached Storage) подключается непосредственно к локальной сети. Пользователь подсоединяется к NAS-серверу напрямую через сеть, в которой он находится. В системе хранения данных NAS-топологии предусмотрены специализированная операционная система и набор утилит для быстрого запуска и обеспечения доступа к файлам. Концепция хранилищ, присоединяемых к сети, развивается как альтернатива универсальным серверам (в отличие от них NAS-устройства выполняют единственную функцию – функцию файлового сервера). NAS подключается к локальной вычислительной сети (далее – ЛВС) и осуществляет доступ к данным для неограниченного количества клиентов с разными операционными системами или для других серверов. Доступ к хранилищам NAS производится с помощью протоколов доступа к файлам: – CIFS (Common Internet File System); – NFS (Network File System); – DAFS (Direct Access File System). На рис. 31 указаны достоинства и недостатки использования NAS-топологии и сферы ее применения. 111

DAS

Достоинства

Применение

Недостатки

Низкая стоимость

Малые офисы

Низкая надежность

Простота развертывания и администрирования

Хостинг-провайдеры

При сбоях теряет возможность разделять данные пользователей

Небольшие корпоративные сети

Высокая скорость обмена между дисковым массивом и сервером

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

Рис. 30. Характеристика DAS-топологии системы хранения данных

Система хранения данных топологии SAN (Storage Area Network) – отдельная сеть для подключения внешних устройств хранения данных (дисковых массивов, ленточных библиотек, оптических накопителей) к серверам таким образом, чтобы операционная система распознала эти ресурсы как локальные. Данное архитектурное решение может расширяться как вертикально (путем добавления дополнительных дисков и полок расширения к единому дисковому хранилищу), так и горизонтально (с добавлением новых хранилищ в инфраструктуру сети). В этом случае серверы получают доступ к дисковым накопителям посредством сети SAN и не нагружают локальную сеть. 112

NAS

Достоинства

Применение

Низкая стоимость Простота развертывания и администрирования Универсальный клиентский опыт для клиентов с разными операционными системами

В случае необходимости создания среды для большого (неограниченного) количества гетерогенных (с различными операционными системами) клиентов и других серверов

Гибкость и масштабируемость

Недостатки Возможность хранения данных только в виде файлов Медленный доступ к информации по сетевым протоколам (по сравнению с локальной системой) Высокая загрузка локальной вычислительной сети Невозможность работы некоторых приложений с сетевыми дисками

Рис. 31. Характеристика NAS-топологии системы хранения данных

Топология SAN также может быть реализована в указанных ниже топологиях, что обеспечивает их повышенную гибкость, надежность и производительность: – точка-точка (прямое подключение сервера к массиву дисков); – петля с арбитражной логикой (далее – FC-AL); – коммутируемое подключение (далее – FC-SW). На рис. 32 указаны достоинства и недостатки использования SANтопологии и сферы ее применения. В основе концепции SAN-топологии системы хранения данных лежит возможность соединения любого сервера с любым устройством хранения данных. Устройства соединяются по протоколу Fibre Channel, который выполняет транспортную функцию, используя медные или оптоволоконные соединения устройств. К составляющим SAN-топологии относятся: – хост-адаптер шины (реализует стек протоколов Fibre Channel); – ресурсы хранения данных (дисковые массивы, ленточные накопители и библиотеки с интерфейсом Fibre Channel); 113

SAN Достоинства Высокая скорость работы, низкая задержка Гибкость и масштабируемость Хранение данных блоками (как, например, для почтовой базы Exchange) Простое использование кэширования данных Универсальность (доступ к данным может получить сервер приложений под управлением любой операционной системы)

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

Использование территориально разнесенных устройств хранения

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

Высокая надежность обмена данными и хранения данных Организация удаленного архивирования и восстановления данных без дополнительных затрат Агрегирование каналов Быстрое подключение устройств Централизованное управление коммутацией и логистикой данных Разгрузка подсети от служебного трафика

Рис. 32. Характеристика SAN-топологии системы хранения данных 114

– инфраструктурные устройства (сетевое оборудование: коммутаторы, концентраторы, маршрутизаторы Fibre Channel); – программное обеспечение (поддерживает таблицу путей доступа к устройствам и обеспечивает отключение путей в случае аварии, динамическое подключение новых путей и распределение нагрузки между ними). Итак, в системах хранения концепция виртуализации может быть реализована на уровне внешней памяти при введении разнородных накопителей (DAS и NAS) в единый пул, а также на уровне сетей хранения (SAN). Топологии DAS, NAS и SAN, появлявшиеся на рынке последовательно, отражают эволюционирующие цепочки связей между приложениями, использующими данные, и байтами на носителе, содержащем эти данные.

Сведения об информационной системе и ее жизненном цикле Лучшим способом претворения в жизнь концепции управления жизненным циклом информации в рамках среднего бизнеса является организация частного корпоративного облака в форме сетевых узлов NAS. Реализация, например, облачного хранения данных осуществляется в соответствии с моделью жизненного цикла информационной системы. В табл. 25 указаны действия, выполнявшиеся на каждом этапе, а также приведен прогноз дальнейшего функционирования этой системы. Длительность каждого этапа жизненного цикла ИС соответствует реальным датам работы, а их стоимость (с учетом оплаты труда с начислениями) определена исходя из реальных затрат в совокупности. Выделены две подсистемы облачного хранилища: – NAS-узел – сервер, предоставляющий службы для хранения данных другим устройствам в сети; – графический интерфейс пользователя GUI (Graphical User Interface) – средства для взаимодействия пользователя с устройством при помощи системных объектов и функций в виде графических компонентов экрана.

Определение требований к системе Для осуществления выбора оборудования и утилит важно определить требования к информационной системе. На выполнение данного этапа ушло 6 рабочих дней (с 1 февраля до 8 февраля 2022 г.). Пользователями облачного хранилища будут сотрудники отделов продвижения и технологического сопровождения. Использование хранилища может потребоваться как в помещении (бизнес-процесс «Поиск потребителей в отраслевых институтах»), так и в полевых условиях (бизнес-процесс «Контроль и поддержка окрасочных работ на объекте»), поэтому скорость и качество интернет-соединения могут варьироваться. Доступ пользователей к данным должен предусматриваться с различных устройств: телефонов 115

116

Надсистема

Стоимость, руб.

Длительность

Компонент модели

Выявление потребности офиса организации в облачном хранилище

19 385

1.02.2022– 8.02.2022

Определение требований к системе

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

34 570

9.02.2022– 21.02.2022

Проектирование Внедрение

4.04.2022– 15.04.2022 30 285 Подготовительные работы по внедрению ИС. Публикация и обновление инструкций

Тестирование

28.03.2022– 4.04.2022 12 580 –

Разработка

22.02.2022– 28.03.2022 114 888 Выделение денежных средств на покупку оборудования и разработку. Извещение будущих пользователей о планируемом внедрении

Вывод из эксплуатации

15.04.2032– 1.05.2032 TBD Коренное изменение в функционировании организации. Продажа оборудования

Эксплуатация и сопровождение

15.04.2022– 15.04.2032 TBD Автоматизация процесса хранения и передачи данных в организации. Помощь пользователям. Оптимизация бизнеспроцессов

Полная модель жизненного цикла информационной системы для организации

Т а б л и ц а 25

117

Проектирование

Написание и согласование технического задания в проектной команде

Определение требований к системе

Безопасность данных. Скорость передачи данных. Адаптивность

Подбор Требования вариантов к NAS-узлу (минимальное NAS и HDD количество пользователей, объем используемого ими трафика и состояние оборудования)

Система (облачное хранилище)

Подсистема 1 (сервер – NAS)

Компонент модели

Покупка «белого» IP-адреса. Инициализация и конфигурация сервера. Импорт пользователей и установка прав доступа. Настройка Active Directory.

Настройка оборудования. Оптимизация облачной среды. Составление инструкций для пользователей

Разработка

Тестирование сетевого оборудования. Исправление ошибок

Ручное и автоматическое тестирование

Тестирование

Вывод из эксплуатации

Извлечение данных с HDD

Прекращение Выявление и устранение работы системы неполадок в работе программного обеспечения. Модернизация хранилища

Эксплуатация и сопровождение

Использование Расширение дискового полных пространства мощностей оборудования

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

Внедрение

П р о д о л ж е н и е т а б л. 25

118

Требования к интерфейсу (возраст пользователей, опыт использования облачных данных и т. п.)

Определение требований к системе

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

Проектирование

Установка пользовательских утилит (в том числе интеграция хранилища с Office). Организация рассылки приглашений для пользователей

Создание частного облака QNAPcloud. «Пробрасывание портов»

Разработка

Тестирование программного обеспечения и элементов интерфейса. Исправление ошибок

Тестирование

Инсталляция программного обеспечения и отладка его работы на устройствах сотрудников

Внедрение

Вывод из эксплуатации

Удаление Совершенпрограммных ствование продуктов интерфейса в соответствии с требованиями пользователей и новых технологий

Эксплуатация и сопровождение

Примечание. TBD (to be determined) будет определена позже; HDD (hard disk drine) – тип накопителя.

Подсистема 2 (пользовательский интерфейс – GUI)

Компонент модели

О к о н ч а н и е т а б л. 25

и планшетов (операционные системы Android и iOS), а также с персональных компьютеров (операционные системы Windows 10, Windows 11, macOS 10.7 и выше). Функциональные требования к облачному хранилищу таковы: – получение доступа с разных устройств; – загрузка и скачивание файлов; – чтение и редактирование документов разных объемов и разных форматов (изображения, текстовые документы, таблицы, презентации и др.); – совместная работа с файлами и общими папками; – контроль доступа к данным. Ранее облачные технологии для хранения данных в организации не использовались, а значит, имеет смысл считать, что опыта работы с подобными сервисами у будущих пользователей нет, поэтому с точки зрения клиентского опыта информационной системе следует обеспечить: – интуитивно понятный интерфейс; – минимальное количество переключений между приложениями; – простой процесс авторизации в системе; – минимальное количество задержек; – высокую адаптивность; – кроссплатформенность. Из данных требований определены следующие целевые показатели уровня обслуживания: – время ожидания ответа не более 120 мс в 98 % случаев; – успешность переноса данных в 99,9 % случаев; – не менее 30 одновременных соединений с системой; – возможность удаленного подключения к системе. Для соответствия информационной системы вышеперечисленным целевым показателям важно определить требования к оборудованию. На момент начала разработки проекта в офисе имелись компьютеры, локальная сеть и безлимитный доступ к сети Интернет. В результате анализа существующей ИТ-инфраструктуры определены следующие требования к сетевому хранилищу: – оперативная память не менее 2 Гб; – частота процессора не менее 2 ГГц; – возможность интеграции хранилища с механизмом доменной аутентификации (поддержка Active Directory).

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

каждому из них памяти и выбран вариант NAS и утилит. Цель проектирования – оптимизация процесса получения сотрудниками информации в командировках путем внедрения корпоративного облачного хранилища. Определены следующие задачи: – выбрать и приобрести оборудование для организации облачной среды; – произвести конфигурирование сетевого хранилища; – создать корпоративное облако; – установить требуемые утилиты; – протестировать облачную среду и устранить ошибки ее функционирования; – составить инструкцию по работе с облачным хранилищем; – бесшовно внедрить облачное хранилище. На реализацию данного проекта организации готова выделить не более 40 000 рублей без учета трудозатрат и не более 2,5 месяца. Этап проектирования, как отмечено выше, включал определение количества пользователей облачного хранилища и объема выделяемой на каждого из них памяти. В бизнес-процессах продвижения и технологического сопровождения участвуют 50 человек, и для оптимизации их работы потребуется не менее 2 720 Гб дискового пространства. С учетом необходимости в резервном пространстве можно сделать вывод, что понадобится жесткий диск (HDD) объемом 3 Тб (табл. 26). Для организации облачной инфраструктуры необходимо приобрести NASоборудование, представляющее собой компьютер с некоторым дисковым массивом, подключенный к сети и поддерживающий работу по принятым в ней протоколам. Список возможных вариантов требовалось составить именно на этом этапе, однако в ценовом сегменте, обусловленном бюджетными ограничениями проекта, присутствовала только одна позиция с необходимыми аппаратными характеристиками. Было выбрано сетевое хранилище QNAP S2 с отсеками для монтажа двух 2,5- или 3,5-дюймовых накопителей с интерфейсами SATA II или III, объем которых может достигать 10 Тб. Данное NAS-оборудование обладает следующими характеристиками: – процессор – четырехъядерный Intel Celeron J1900 с частотой 2,0 ГГц; – оперативная память – 2 048 МБ. В качестве накопителя выбран диск Toshiba P300 на 3 Тб с интерфейсом SATA III и пропускной способностью 6 Гбит/с. Пользователям облачного хранилища предстоит работать с операционной системой QTS 4.0 (системное ядро – Linux) и взаимодействовать с приложениями от компании QNAP: – myQNAPcloud Link (служба удаленного доступа myQNAPcloud); – File Station 5 (файловая служба); – QFile (мобильный клиент). Безопасность будет обеспечиваться с применением Malware Remover (сканера безопасности) и QuFirewall (межсетевого экрана). Открывать и редак120

Т а б л и ц а 26 Распределение дискового пространства Количество пользователей, чел.

Объем корпоративных данных, Гб/чел

Минимальное дисковое пространство, Гб

Первый вице-президент по коммерческой деятельности

1

200

200

Коммерческий директор

1

200

200

Отраслевые директора

6

200

1 200

Отраслевая дирекция (менеджеры по проектам в нефтегазовом комплексе, транспортном мостостроении, промышленно-гражданском строительстве, военно-промышленном комплексе, в энергетике и гидросооружениях, в судостроении)

22

30

660

Организационное Группа огнезащитных материалов сопровождение (руководители и проектировщики)

4

20

80

Специалисты по тендерам

2

10

20

Группа по работе с договорами

3

10

30

11

30

330

50

700

2 720

Показатель

Продвижение продукции (поиск потребителей в отраслевых институтах)

Пользователь / сущность

Технологическое Технологи (база опыта по окрасочсопровождение ным работам) Итого

тировать документы пользователи смогут с помощью программ Office Online, Google Docs или Office Editing. Физическая установка сетевого хранилища осуществляется следующим образом: – жесткий диск помещается в сетевой накопитель; – к NAS-оборудованию подсоединяются сетевой кабель и шнур блока питания; – NAS-оборудование подключается через сетевой кабель к switch. Завершив установку сетевого хранилища, нужно убедиться, что устройство функционирует правильно, и выполнить вход в QTS с указанием имени пользователя и пароля учетной записи admin. Далее производятся инициализация и первичная настройка устройства через микропрограммы Qfinder Pro. Устанавливается название NAS. В дальнейшем сетевой узел 121

будет фигурировать в данной работе под кодовым названием NarniaWorld, поскольку было принято решение не разглашать название, применяемое в офисе АО НПХ ВМП. После этого создается пароль учетной записи admin и настраиваются дата и время. Следующий шаг – получение IP-адреса при помощи протокола прикладного уровня DHCP (Dynamic Host Configuration Protocol) для работы в сети, что упрощает процесс администрирования в ней устройств и позволяет избежать ошибок. Затем требуется произвести загрузку надстроек, позволяющих осуществлять кроссплатформенную работу с файлами, что было одним из основных требований к системе. Для обеспечения полной гибкости сетевого хранилища использовались все возможные операционные системы. Последним шагом инициализации устройства является выбор дисковой конфигурации. После инициализации сетевого узла обеспечивается безопасность устройства и настраивается политика расширенного уровня безопасности. Для этого осуществляются следующие действия: – устанавливается межсетевой экран QuFirewall; – применяется сертификат сервера Secure Sockets Layer (далее – SSL-сертификат); – назначается политика паролей; – обеспечивается защита доступа к IP-адресам путем его ограничения; – устанавливается сканер безопасности Malware Remover; – подключается утилита Security Counselor для контроля политики безопасности. После обеспечения безопасности информационной системы конфигурируется сервер по протоколу SMTP для пересылки электронных писем с сервера отправителя (из хранилища) на сервер получателя (пользователям). Так пользователи системы смогут получать уведомления о работе сетевого хранилища. Для того чтобы работники отделов продвижения и технологического сопровождения могли пользоваться сетевым хранилищем, требуется создать каждому из них учетную запись QNAP ID, а также зарегистрировать подключаемое в систему устройство. С тем чтобы контролировать доступ, важно настроить Active Directory – службу каталогов для аутоинтефикации, управления группами и пользователями. Для этого производятся настройка системы доменных имен (далее – DNS) и синхронизация времени сетевого накопителя с контроллером домена. Адрес DNS-сервера получают по DHCP-протоколу. В результате сетевой накопитель включается в домен Active Directory. С целью улучшения управления доступом также применяется протокол прикладного уровня LDAP для взаимодействия с другими серверами служб каталогов. Пользователей в хранилище добавляют двумя способами: с помощью ручного ввода и путем импорта из базы данных. 122

Для разграничения прав доступа созданы две группы: «Продвижение» и «Технологическое сопровождение». Помимо папки home, которая является персональной для каждого пользователя, у группы «Технологическое сопровождение» есть право на чтение общей папки «База опыта по окрасочным работам» и на записи в ней. Очередной шаг – организация частного облака на базе программы myQNAPcloud. В первую очередь производится регистрация NAS-сервера в панели управления myQNAPcloud. В результате регистрации появляются интернет-адрес и утилита SmartURL, через которые пользователи смогут получить доступ к накопителю. Далее следует активизация DDNS для установления соединения с устройством через Интернет и с облачным хранилищем myQNAPcloud Link для удаленного доступа к NAS на веб-сайте myQNAPcloud и подключения через мобильные приложения. В результате NAS-узел становится облачным хранилищем. Также облачное хранилище для редактирования в нем документов интегрируют с программой Office Online с приложениями путем применения открытого протокола WOPI. После отладки функционирования разработанной информационной системы создаются тестовые пользователи на тестовых устройствах. Возможны проблемы с доступом к панели управления, в этом случае требуется переустановить сертификат безопасности. Тестирование жесткого диска выполняется при помощи механизма самопроверки дисков S.M.A.R.T (Self-monitoring, Analysis and Reporting Technology). В ходе тестирования диска проверяются возможности доступа к файлам с различными ограничениями в правах. Вручную можно проверить реактивность интерфейса, время на авторизацию (в среднем 15 с), скорость загрузки и чтения файлов (в среднем 6 Мб/с и 15 Мб/с). По результатам тестирования система должна соответствовать установленным критериям SLO. Для каждого пользователя предусмотрены приложение Qfinfer для поиска NAS в сети и приложение Qfile для работы с документами с телефона. Инсталляция и отладка работы программного обеспечения должны быть произведены без отвлечения сотрудников офиса от выполнения ими их обязанностей. Необходимо также учесть пожелания сотрудников и обновить инструкцию. Пользователь может получить доступ к данным одним из трех способов: через панель управления QNAP – в QTS, через веб-приложение myQNAPcloud или через мобильное приложение Qfile. Таким образом, сотрудники отделов продвижения и технологического сопровождения при поездках в командировки могут оперативно получать доступ к корпоративным данным. 123

Облачная система хранения данных должна функционировать на протяжении как минимум 10 лет. В процессе эксплуатации информационной системы могут и должны быть выявлены и устранены неполадки в работе программного обеспечения. На данном этапе потребуется следить за удобством использования системы работниками, отвечать на возникающие вопросы и вносить в ИС необходимые изменения. Также нужно будет обеспечить хранение данных в соответствии с концепцией управления жизненным циклом информации (ILM): – обновлять целевые показатели надежности системы; – реализовать автоматическую выгрузку требующихся для командированных сотрудников данных из 1С: Документооборот; – производить архивирование данных по окончании работы с клиентом. Можно расширить дисковое пространство путем добавления в систему хранения данных NAS одного жесткого диска. За 10 лет функционирования созданной облачной системы хранения данных технологии могут поменяться, и эта система может утратить актуальность, а действия по ее совершенствованию могут перестать окупаться. В таком случае необходимо будет вывести систему из эксплуатации: извлечь с жестких дисков данные и переместить их в новое оборудование. После этого потребуется выставить на продажу оборудование, выведенное из эксплуатации. На все это уйдет около полутора месяцев.

124

3. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ИТ-ПРОЕКТА

3.1. Основные правила экономического обоснования ИТ-проекта Проектирование, внедрение и дальнейшее сопровождение информационной системы требуют финансовых вложений, которые для крупных систем оцениваются значительными объемами. Отсюда возникает вопрос об окупаемости новой системы, что обусловливает необходимость обоснования не только целесообразности, но и экономической эффективности ее создания, оценки ожидаемых результатов от функционирования ИС и затрат, необходимых для разработки, ввода в действие и поддержки данного продукта. Результаты оценки экономической эффективности ИТ-проекта отражаются в таких документах, как «ИТ-стратегия», «Технико-экономическое обоснование создания ИС», а также могут содержаться в специальных разделах Отчета об обследовании, Документ-концепции ИС, в приложении к Техническому заданию на создание ИС. Поскольку вопрос финансовых затрат поднимается на протяжении всего жизненного цикла информационной системы, на каждом его этапе, рассчитывать экономическое обоснование имеет смысл только на основе жизненного цикла разрабатываемой ИС, иначе обоснование будет неполным. Для определения жизненного цикла информационной системы удобно заполнить таблицу, содержащую все этапы жизненного цикла ИС каскадной модели (табл. 27), где: – надсистема – это организация (заказчик), для которой разрабатывается ИС; – информационная система – непосредственно разрабатываемая ИС; – подсистема – компоненты, из которых состоит ИС (например, модуль отчетов, текстовый модуль, интерфейс). Каждый из перечисленных выше элементов необходимо рассмотреть в разрезе этапов жизненного цикла, подробное содержание которых представлено в первой главе данного пособия. Указание длительности этапов, сроков начала и окончания жизненного цикла информационной системы превращают данную таблицу (см. табл. 27) в план проекта. Очевидно, что перечень этапов может не совпадать с календарными месяцами: один этап не обязательно равен одному месяцу работы. 125

Модернизация / вывод из эксплуатации

Эксплуатация / сопровождение

Тестирование / отладка

Разработка

Проектирование

Показатель

Анализ требований

Т а б л и ц а 27 Пример жизненного цикла информационной системы в каскадной модели

Дата начала этапа Дата окончания этапа Надсистема / надсистемы ИС (название) Информационная система (название) Подсистема / подсистемы ИС (название) Итого денежные затраты Итого временные ´ затраты

Экономическую выгоду приносит только этап эксплуатации сопровождения (также требующий вложений, но приносящий доход), а на всех пре´ и финансовые) дыдущих этапах необходимы только вложения (временные для того, чтобы этой выгоды добиться. При расчете и планировании затрат по этапам следует ориентироваться на установленные ранее экономичес´ ограничения на проект. Если затраты и сроки эти ограникие и временные чения превысят, нужно либо пересмотреть проект, либо отказаться от него. После описания жизненного цикла разработки информационной системы необходимо провести экономические расчеты продукта. Ориентируясь на построенные ранее модели бизнес-процессов AS-IS и TO-BE, определяются условия до и после внедрения новой ИС (табл. 28). Для того чтобы понять, когда выгода от внедрения новой информационной системы превысит первоначальные затраты на нее, строится график, иллюстрирующий расходы до и после внедрения ИС, где по горизонтальной оси накопительным итогом отражается количество исполняемых задач до и после внедрения системы отдельно, а по вертикальной – затраты на обеспечение исполнения этих задач. Данные до внедрения информационной системы должна предоставить организация, чья проблема решается в проекте, а данные после внедрения ИС должны соответствовать ожидаемым значениям эффективности, указанным в требованиях к разработке этого продукта. 126

Т а б л и ц а 28 Экономические условия до и после внедрения информационной системы До внедрения ИС

После внедрения ИС

Время на одну задачу, ч

Время на одну задачу, ч

Стоимость обеспечения исполнения одной задачи, руб./мес.

Стоимость обеспечения исполнения одной задачи, руб./мес.

И т. д.

И т. д.

Для расчета баланса организации, ожидаемого от внедрения информационной системы, необходимо рассчитать ожидаемые доходы, ожидаемые расходы и вычислить их разницу: Баланс = Ожидаемые доходы – ожидаемые расходы. В процессе работы строятся графики зависимостей: – затрат (по вертикали) от времени по месяцам (по горизонтали); – доходов (по вертикали) от времени по месяцам (по горизонтали).

3.2. Функции для экономического обоснования эффективности проекта Понятие эффективности проекта Эффективность проекта – та категория, которая отображает соответствие затрат и результатов инновационного проекта интересам и целям участников; здесь могут также учитываться интересы государства и населения. В настоящее время можно считать общепризнанным выделение следующих видов эффективности проектов (рис. 33): – эффективность проекта в целом; – эффективность участия в проекте. Эффективность проекта в целом определяется для того, чтобы оценить его потенциальную привлекательность для вероятных участников, а также с целью поиска инвесторов. Этот вид эффективности включает эффективность общественную (социально-экономическую) и эффективность коммерческую. Эффективность участия в проекте определяется для того, чтобы оценить реализуемость проекта, а также заинтересованность в проекте его участников. 127

Эффективность проекта в целом

Общественная эффективность

Эффективность участия в проекте

Коммерческая эффективность

Эффективность участия организаций

Эффективность инвестирования в акции

Эффективность участия в проекте структур более высокого уровня

Бюджетная эффективность

Рис. 33. Виды эффективности проектов

Эффективность участия в проекте включает: – эффективность для организаций-участников; – эффективность инвестирования в акции организации (эффективность для акционеров); – эффективность участия в проекте структур более высокого уровня по отношению к организациям – участникам инвестиционного проекта, в том числе региональную и народнохозяйственную, отраслевую эффективность.

Подходы к оценке экономической эффективности проекта Для оценки экономической эффективности проекта по внедрению информационных систем разработаны 2 подхода. 1. Условная оценка экономической эффективности. Задействуется такая оценка в том случае, когда руководитель понимает, для чего его организации требуется IT-проект, и готов взять на себя ответственность за его воплощение в реальность. При этом точно определить уровень отдачи посредством применения методов числовой оценки сложно. 2. Формальная оценка эффекта от внедрения. Здесь используются количественные показатели, чтобы рассчитать эффект от внедрения программы. К количественным показателям относят издержки на разработку проекта, расходы на покупку, установку, настройку и поддержку программного обеспечения. Дополнительно учитываются расходы на обучение персонала, поддержку технических средств, покупку оборудования. Практика подтверждает, что оценить эффективность IT-проекта сложно. Все информационные технологии обычно нацелены на воплощение сервис128

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

Экономические методы оценки Метод Total Cost of Ownership (TCO) Метод ТСО используется для оценки совокупности затрат. Он был разработан в 80-х годах ХХ века. В основе данного метода лежит сравнение двух вариантов ИТ-компонентов. При оценке методов TCO учитывают и проектные, и операционные издержки. TCO = стоимость покупки + (эксплуатационные расходы  время). К проектным расходам относят: – компьютерное и серверное оборудование; – инсталляцию и интеграцию; – оплату услуг субподрядчиков. Сюда же можно отнести издержки на сервисное и гарантийное обслуживание, на переходные процессы и на лицензию. К операционным расходам относят: – регламентные работы; – работу с ошибками, сбоями; – модернизацию оборудования; – услуги по консультациям, советам, рекомендациям; – восстановление и резервное копирование; – внешний аудит. Благодаря методу Total Cost of Ownership можно определить общую величину целевых затрат, которую несет инвестор с момента начала реализации проекта. Метод Return of Investment (ROI) В основе этого метода лежит коэффициент возврата инвестиций. Метод ROI используется при расчете эффективности инвестиционных вложений. Его также можно применять при оценке ИТ-проектов для расчета совокупной прибыли. Расчет позволяет определить время, при котором прибыль от внедрения программы покроет стоимость инвестиционных затрат. Многие финансовые директора требуют показателей ROI. Однако в CRM рассчитать их тяжело. Это обуславливается успехом от реализации IT-программ и зависит в большей степени от восприятия ее конечными пользователями. 129

ROI =

Доход от проекта – затраты на проект            100 %. Затраты на проект

На практике экономические методы оценки далеко не всегда дают точный результат, так что вычислить финансовый эффект затруднительно. Тем не менее многие инвесторы до сих пор требуют от руководителя проекта именно расчеты ROI и TCО.

Системные методы оценки Достойной альтернативой экономическим методам оценки являются системные методы. В их основе лежит учет различных показателей, что позволяет понять реальную пользу от программы в разных областях деятельности конкретной организации. Рассмотрим главные системные методы оценки. Метод Balanced Score Card (BSC) Метод BSC предусматривает систему показателей, в которой выделяют 4 компонента: финансы, клиенты, внутренние бизнес-процессы, обучение персонала. В 90-х годах метод BSC был усовершенствован: скорректирован именно под информационные технологии. В результате появился метод Balanced IT Scorecard (BITS), спецификой которого являются: – ориентация на будущее (включает в себя развитие ИТ-архитектуры, анализ качества управления персоналом, усовершенствование технологий, улучшение производительности сервисов); – ориентация на потребителя (делается акцент на поддержку качества, улучшение удовлетворенности клиента, доработку софта); – вклад в развитие организации (акцент на стратегических проектах, формирование синергии на поглощение и слияние компаний); – операционные преимущества (качественное повышение производительности труда, нацеленность на результат и безопасность применения софта). Метод BITS зарекомендовал себя положительно, поэтому он активно применяется сегодня при оценке экономической эффективности разнообразных ИТ-проектов. Метод Performance Reference Model (PRM) Представляет собой референсную модель производительности. Впервые метод PRM был разработан на территории США для оценки эффективности IT-программ. С его помощью: – увеличивают объем выполняемых транзакций; – добиваются улучшения результата с учетом главной миссии организации; – расширяют практические возможности; – повышают экономическую эффективность. 130

На практике метод PRM позволяет также улучшить качество оказываемых организацией услуг, поэтому он успешно применяется в разных ИТ-проектах. Эталонная модель производительности включает область цели и область измерения. Область цели. Цель позволяет идентифицировать общие элементы производительности в рамках инвестиций или видов деятельности, а в будущем создаст условия для кроссплатформенных информационных связей между такими системами, как Performance.gov и информационная панель ИТ, что обеспечит логические взаимосвязи, необходимые для последовательного предоставления гораздо более глубокого понимания деталей поддерживаемых областей производительности, чем это было возможно ранее. Область измерения. Здесь описывается способ, которым инвестиции или деятельность способствуют достижению поддерживаемого элемента производительности. Области измерения применяются к более подробным показателям эффективности, связанным с инвестициями в деятельность, а не с функциями инвестиций или деятельности. Показатели эффективности инвестиций или деятельности, конечно, должны иметь четкую привязку к видам деятельности, но важно понимать, что инвестиции или виды деятельности могут соответствовать нескольким областям измерения. Любая категория измерения может быть применена к любой цели. Метод Business Value of IT (BVIT) Данный метод был впервые разработан корпорацией Gartner Group для реализации стратегии TVO (Total Value of Opportunity). В его основе лежит анализ бизнес-ценностей цифровых технологий, где принятие решения об инвестировании выполняется на основе 5 главных факторов. Фактор 1. Точная окупаемость. Смогут ли инвестиции принести в ИТ дополнительную прибыль организации? Улучшить качество продукта или услуги? Оптимизировать расходы, издержки? Фактор 2. Стратегическое согласование. Будет ли способствовать такой проект достижению главной стратегической цели организации? Фактор 3. Степень воздействия на бизнес-процессы в организации. Речь идет о прямом влиянии на изменение бизнес-процессов в организации. Фактор 4. Изменение архитектуры организации. Приведет ли внедрение проекта к изменению структуры организации? Фактор 5. Анализ потенциальных рисков. Имеются ли для вложения (денег) в бизнес технологические и прочие риски? Только тщательно проанализировав все 5 факторов, можно принять решение относительно вложения денежных средств. 131

Метод ITIL Service Strategy Представляет собой сервисную стратегию. В ее основе лежит системный подход, позволяющий оценить влияние на проект операционной, финансовой, рыночной и стратегической сфер. 1. Операционная сфера. Предусматривает сокращение времени разработки, увеличение мощности, снижение финансовых рисков, а также улучшение эффективности и грамотное использование ресурсов. 2. Финансовая сфера. Включает сокращение затрат, рост доходов, увеличение дискреционных расходов. Параллельно предусматривается возврат на инвестиции, выполнение бюджета и рост маржи. 3. Рыночная сфера. Обуславливает рост доли рынка, стремление занять лидерские позиции и увеличить стабильность бизнеса. В качестве дополнения можно выделить улучшение рыночной позиции, соответствие продукта или услуги стандартам. 4. Стратегическая сфера. Разработка и укрепление рыночных позиций, рост удовлетворенности товарами. Параллельно можно выделить улучшение качества товара, предложение новых продуктов и услуг, а также создание конкурентных товаров.

Главные критерии оценки экономической эффективности проекта Под критериями оценки подразумеваются ориентиры, принимаемые за основу в процессе разработки и внедрения проекта. Каждый критерий оценки результативности проекта обладает конкретными особенностями. Простая норма прибыли (SRR). Отображает ту часть денежных средств, которые возмещаются за счет прибыли в течение планируемого интервала. Критерий SRR позволяет быстро оценить проект: SSR =

NP ×100 %, TIC

где NP – чистая прибыль за период; TIC – полные инвестиционные затраты. Срок окупаемости вложенных денежных средств (PP). Данный критерий позволяет проанализировать, в течение какого периода времени будут возвращены первоначальные инвестиции. PP = I0 / P, где I0 – первоначальные инвестиции; P – чистый годовой поток денежных средств от реализации проекта. Чистая приведенная стоимость (Net Present Value, NPV). Обычно этот показатель используют, чтобы понять, стоит ли вкладывать деньги в проект. Иногда с его помощью рассчитывают финансовые характеристики за определенный период времени. 132

T

NCFt – I0 , t t  0 (1  i )

NPV = 

где t, …, T – временной отрезок, за который производится расчет; NCF – денежный поток за выбранный интервал времени; i – ставка дисконтирования; I0 – капитал, вложенный на этапе первоначальных инвестиций. Например, инвестор хочет вложить 5 миллионов рублей. Его интересуют сроки окупаемости проекта и возможный заработок. Показатель NPV позволит понять, каким будет размер чистой прибыли через 1 год, 5 или 10 лет. От результатов его расчета часто зависит окончательное решение – насколько целесообразно вкладывать деньги в конкретный проект. Если результат подсчета NPV проекта оказывается положительным, проект экономически эффективен, и потенциальные инвесторы обратят на него больше внимания. При расчете NPV можно учитывать разные сроки, складывать показатели отдельных проектов и принимать во внимание дополнительные риски. Все это – неоспоримые преимущества расчета NPV. Одной из самых сложных составляющих при расчете NPV является учет всей массы денежных потоков. Для этого необходимо соотнести размер первоначально вложенного капитала, а также ожидаемую прибыль и планируемые расходы в будущем. Под денежными потоками понимают все финансовые поступления и расходы. Под поступлениями чаще всего подразумеваются продажи, хотя встречаются и другие их виды (например, проценты от проведенных сделок). Расходы включают в себя выплату заработной платы сотрудникам, коммунальные платежи, закупку сырья, аренду помещений, обустройство рабочих мест, налоги. Существуют также предположительные потоки, и рассчитать их гораздо сложнее (например, грядущее повышение арендной ставки или затраты на запуск на рынок нового продукта). В качестве аналитической базы используют экономические показатели, результаты мониторинга конкурентов, ожидаемый эффект от рекламы и другие данные. Узнать NPV проекта невозможно без ставки дисконтирования. Далеко не все инвесторы вкладывают собственные средства – иногда выгоднее взять кредит, чем использовать внутренние ресурсы. Или можно продать акции, если потенциальная прибыль у проекта выше, чем их доходность. Посчитать ставку в случае кредита проще. Достаточно ориентироваться на годовой процент. Если же инвестор планирует использовать деньги с продаж акций, придется сравнивать прогнозы по доходам. Предположим, что в проект инвестировали 1 000 000 рублей. В качестве периода расчета NPV выбрали 1 год. Ставка дисконтирования равна 15 %. 133

Обычно ее переводят в коэффициент, то есть делят на 100. Если размер денежных поступлений составит 900 000 рублей, получится: 900 000 / (1 + 0,15) – 1 000 000 = –217 391 (руб.). Эта сумма и будет чистой стоимостью, приведенной за год. Поскольку она отрицательная, проект считается убыточным в выбранном периоде. Но это не значит, что вложения не окупятся, – просто нужно увеличить временной отрезок и использовать формулу

NPV =

NCF1 NCF2 NCF3 NCF4 + + + – I0 . 2 3 (1  i ) (1  i ) (1  i ) (1  i ) 4

С каждым годом коэффициент дисконтирования уменьшается, поэтому его нужно возводить в степень. Если взять предыдущий пример, за 3 года получится следующий результат: 900 000 / (1 + 0,15) + 900 000 / (1 + 0,15) 2 + + 900 000 / (1 + 0,15) 3 – 1 000 000 = 1 054 902 (руб.). Так как сумма положительная, проект на этом промежутке времени оказывается прибыльным. Внутренняя норма доходности (ВНД). Внутренняя норма доходности – это такая ставка дисконтирования, при которой инвестор получит назад все вложения, то есть выйдет в ноль. В учебниках можно встретить и такие наименования этого показателя, как ВСД, IRR. Чем выше ВНД, тем выше доходность проекта, потому что можно заложить больше рисков. И вот этот показатель можно и нужно рассчитывать с помощью конкретной формулы, чтобы определить доходность проекта. ВНД – это уровень выхода в ноль, при котором чистая приведенная стоимость (NPV), соответственно, равна нулю. Для расчета нормы доходности используют формулу с известным NPV, равным нулю:

NPV =

NCF1 NCF2 NCF3 NCF4 + + + – I 0 = 0. 2 3 (1 + IRR) (1 + IRR) (1 + IRR) (1 + IRR)4

Рассчитать это арифметически не получится. В экономических учебниках описываются 2 «ручных» варианта. С помощью одного варианта сначала рассчитывают график NVP для каждого проекта и затем находят IRR на нулевом уровне. Второй вариант, метод подбора, требует знания логарифмических расчетов. Для вычисления можно использовать программы типа Excel. Расчет показателя есть как в платном пакете MS Office, так и в бесплатных Google-таблицах. Для того чтобы узнать ВНД с помощью таблицы в Excel, нужно: 1) кликнуть на пустой ячейке под проектом расчета NPV; 2) выбрать «Вставка»  «Функция»  «Финансовые функции»   IRR (ВСД); 134

3) затем или выделить нужные ячейки, или добавить номера ячеек для вычисления вручную: от отрицательного значения инвестиций до последнего периода денежного потока. К более сложным критериям можно отнести чистый дисконтированный ´ ценность денежных ресурсов. доход, индекс доходности, а также временную Здесь применяется уже более сложная формула расчета, зато и результат получается более объективным. Используемые в настоящее время оценочные критерии позволяют проанализировать аргументы и принять грамотное, взвешенное решение относительно целесообразности внедрения проекта. Такую работу должны выполнять сотрудники, обладающие квалификацией, опытом работы, углубленными знаниями в области проектного управления.

3.3. Расчет экономического обоснования внедрения информационной системы Инвестиционные вложения в проект можно разделить на три категории: затраты на оплату труда, материальные вложения и нематериальные вложения. На этапе инвестиций для выполнения работ по проекту из числа сотрудников организации формируется временная команда специалистов. В расчет берутся специалисты, участвующие в реализации проекта и в опытной эксплуатации внедренного решения. Стоимость одного часа работы на этапе инвестиций приведена в табл. 29. Т а б л и ц а 29 Стоимость одного часа работы на этапе инвестиций

Должность специалиста

Зарплата Затраты Затраты Зарплата НДФЛ, «на руки» + Страховые на оплату на оплату «на руки», взносы, руб./мес. НДФЛ, труда, труда, руб./мес. руб./мес. руб./мес. руб./мес. руб./ч

Руководитель проекта

45 000

6 724,14 51 724,14 15 620,69 67 344,83

401

Разработчик

40 000

5 977,01 45 977,01 13 885,06 59 862,07

356

Веб-разработчик

40 000

5 977,01 45 977,01 13 885,06 59 862,07

356

Дизайнер

20 000

2 988,51 22 988,51

6942,53

29 931,03

178

Тестировщик

20 000

2 988,51 22 988,51

6942,53

29 931,03

178

Бизнес-аналитик

30 000

4 482,76 34 482,76 10 413,79 44 896,55

267

135

Справочные величины по использованным в расчетах налогам и страховым взносам приведены в табл. 30. Т а б л и ц а 30 Справочные величины по налогам и страховым взносам Единица измерения

Величина

Ставка НДФЛ

%

13

Страховые взносы

%

30,2

В том числе: пенсионное страхование

%

22,0

медицинское страхование

%

5,1

социальное страхование

%

2,9

взносы на травматизм

%

0,2

Расчетное количество часов: кол-во рабочих часов в месяце

ч

168

кол-во рабочих дней в месяце

дн

21

кол-во рабочих часов в день

ч

8

Показатель

Расчет затрат на оплату труда на этапе инвестиций приведен в табл. 31. Т а б л и ц а 31 Затраты на оплату труда на этапе инвестиций Трудозатраты, ч

Ставка, руб./ч

Затраты на оплату труда, руб.

Руководитель проекта

116

401

46 516

Разработчик

220

356

78 320

Веб-разработчик

24

356

8 544

Дизайнер

43

178

7 584

Тестировщик

104

178

18 512

Бизнес-аналитик

108

267

28 836

Этап проекта / специалист

Итого

188 312

Материальные и нематериальные вложения, которые потребуются на этапе инвестиций, представлены в табл. 32, 33. 136

Т а б л и ц а 32 Материальные вложения на этапе инвестиций Категории и статьи вложений

Наименование

Количество

Цена без НДС, руб.

Стоимость без НДС, руб.

I

Материальные вложения

–

–

75 362

А

Персональная техника

–

–

75 362

1

Ноутбук Acer ASPIRE 5 (A515-51G)

1

40 000

40 000

2

Монитор HP 22w (1CA83AA)

2

7 490

14 980

3

250 ГБ SSD-накопитель Samsung 860 EVO [MZ-76E250BW]

1

4 399

4 399

4

Жесткий диск WD Gold WD2005FBYZ, 2ТБ, HDD, SATA III, 3.5"

2

7 992

15 983

Т а б л и ц а 33 Нематериальные вложения на этапе инвестиций Категории и статьи вложений

Наименование

Цена без НДС, руб.

Стоимость без НДС, руб.

II

Нематериальные вложения

7 000

А

Облачные сервисы и услуги связи

7 000

1

Организация канала доступа по сети Интернет

6 000

6 000

2

Аренда облачного сервера FirstByte

1 000

1 000

Накладные расходы на этапе инвестирования приведены в табл. 34. Для расчета взят принятый в организации процент накладных расходов от суммы затрат на оплату труда задействованных в проекте специалистов. На этапе эксплуатации проекта поддержку работы сотрудников с информационной системой обеспечивает руководитель проекта. Разработчик выполняет сервисное обслуживание ИС и техническую поддержку пользователей. Затраты на оплату труда сотрудников, а также на бумагу и расходные материалы для их деятельности учтены при расчете экономического эффекта от внедрения. Стоимость одного часа работы на этапе эксплуатации приведена в табл. 35. Эксплуатация осуществляется на регулярной основе. 137

Т а б л и ц а 34 Накладные расходы на этапе инвестиций Показатель

Наименование

Статья накладных расходов

Содержание показателя

–

–

1

Рабочее место

Помещение, уборка, электроэнергия, мебель

2

Управленческие расходы

Руководство организации + бухгалтерия

3

Канцелярские товары

Офисная бумага, маркеры, папки

Метод расчета накладных расходов

–

[A]

Сумма трудозатрат в денежных единицах, руб.

188 312

[B]

Принятая доля накладных расходов от [A], %

15

[C]

Накладные расходы в денежных единицах, руб.

28 247

Доля от трудозатрат в денежных единицах, %

Т а б л и ц а 35 Стоимость одного часа работы на этапе эксплуатации

Должность специалиста

Затраты Зарплата Затраты Зарплата НДФЛ, «на руки» + Страховые на оплату на оплату «на руки», взносы, руб./мес. труда, НДФЛ, труда, руб./мес. руб./мес. руб./ч руб./мес. руб./мес.

Разработчик

40 000

5 977,01 45 977,01 13 885,06 59 862,07

356

Руководитель проекта

45 000

6 724,14 51 724,14 15 620,69 67 344,83

401

138

Расчет затрат на оплату труда на этапе эксплуатации за месячный период приведен в табл. 36. Т а б л и ц а 36 Затраты на оплату труда на этапе эксплуатации (еж емесячные) Трудозатраты, ч

Специалист

Затраты на оплату труда, руб.

Ставка, руб./ч

Подготовка аналитических отчетов Руководитель проекта

401

5

2 005

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

5

401

2 005

Техническое обеспечение работы компьютерной техники, сетевого оборудования, резервирование данных, администрирование программного обеспечения 356

10

Разработчик

3 560 7 570

Итого

Материальные вложения на этапе эксплуатации не требуются, поскольку все необходимое оборудование было приобретено на этапе инвестирования. Нематериальные вложения на этапе эксплуатации представлены из расчета на месяц в табл. 37. Т а б л и ц а 37 Нематериальные вложения на этапе эксплуатации (ежемесячные) Категории и статьи вложений

Наименование

Количество

Цена без НДС, руб.

Стоимость без НДС, руб.

I

Нематериальные вложения

–

–

10 000

А

Работы и услуги внешних исполнителей

–

–

10 000

1

Техническая поддержка и сопровождение системы мониторинга

1

5 000

5 000

2

Доработка функциональности системы мониторинга

1

5 000

5 000

Накладные расходы на этапе эксплуатации приведены в табл. 38. Для расчета взят принятый в организации процент накладных расходов от суммы затрат на оплату труда задействованных в проекте специалистов. 139

Т а б л и ц а 38 Накладные расходы на этапе эксплуатации (ежемесячные) Показатель

Наименование

Статья накладных расходов

Содержание показателя

–

–

1

Рабочее место

Помещение, уборка, электроэнергия, мебель

2

Управленческие расходы

Руководство организации + бухгалтерия

3

Канцелярские товары

Офисная бумага, маркеры, папки

Метод расчета накладных расходов

–

[A]

Сумма трудозатрат в денежных единицах, руб.

7 570

[B]

Принятая доля накладных расходов от [A], %

15

[C]

Накладные расходы в денежных единицах, руб.

1 136

Доля от трудозатрат в денежных единицах, %

Экономический эффект от реализации проекта для заказчика заключается в уменьшении стоимости процесса мониторинга системы безопасности. Для оценки эффекта взята разница в стоимости процессов AS-IS и TO-BE. Расчет стоимости выполнен с помощью метода функциональностоимостного анализа (далее – ФСА). В табл. 39 приведена стоимость одного часа работы специалистов, задействованных в основном бизнес-процессе. В табл. 40 приведен расчет затрат на оплату труда специалистов, задействованных в оказании услуг мониторинга системы безопасности AS-IS и TO-BE. Расчет основан на почасовых ставках и количестве часов в месяц, затрачиваемых работниками на каждый подпроцесс в рамках основного бизнес-процесса организации – AS-IS. Ожидается, что использование автоматизированной системы мониторинга позволит сократить количество задействованных в мониторинге сотрудников за счет выполнения информационной системой некоторых функций без их участия. 140

Т а б л и ц а 39 Стоимость одного часа работы администратора информационной системы и инженера по информационной безопасности Должность специалиста

Зарплата Затраты Затраты Страховые Зарплата на оплату на оплату НДФЛ, «на руки» + взносы, «на руки», руб./мес. НДФЛ, труда, труда, руб./мес. руб./мес. руб./мес. руб./мес. руб./ч

Администратор

45 000

6 724,14 51 724,14 15 620,69 44 896,55

401

Инженер по информационной безопасности

30 000

4 482,76 34 482,76 10 413,79 67 344,83

267

Т а б л и ц а 40 Затраты на оплату труда специалистов, осуществляющих мониторинг системы безопасности AS-IS и TO-BE AS-IS

TO-BE

Ставка, руб./ч

Трудозатраты, ч

–

–

68 090

0

14 690

Администратор

401

10

4 010

10

4 010

Инженер по информационной безопасности

356

180

64 080

30

10 680

–

–

14 240

–

3 560

администратор

401

0

0

0

0

инженер по информационной безопасности

356

40

14 240

10

3 560

защита от угрозы

–

–

28 480

–

3 560

администратор

401

0

0

0

0

инженер по информационной безопасности

356

80

28 480

10

3 560

–

–

25 370

–

7 570

администратор

401

10

4 010

10

4 010

инженер по информационной безопасности

356

60

21 360

10

3 560

Этап проекта / специалист

Обеспечение информационной безопасности в организации

В том числе: мониторинг

расследование инцидентов

141

Затраты ТрудоЗатраты на оплату затраты, на оплату труда, ч труда, руб. руб.

При расчетах учтены следующие показатели переменных затрат (суммы без НДС 20 %): а) аренда помещения 500 000,00 руб./мес.; б) коммунальные услуги 30 000,00 руб./мес.; в) канцтовары и расходные материалы 5 000,00 руб./мес.; г) расходы на оплату труда работников. Ожидается, что сокращение трудозатрат инженеров по информационной безопасности в основном бизнес-процессе позволит снизить расходы в организации. Результаты функционально-стоимостного анализа бизнеспроцесса мониторинга безопасности в организации AS-IS и TO-BE представлены в табл. 41. Т а б л и ц а 41 Функционально-стоимостный анализ основных бизнес-процессов AS-IS и TO-BE Стоимость ресурсов, руб./мес. Перечень ресурсов

AS-IS

TO-BE

Аренда помещения

500 000

500 000

Коммунальные услуги

30 000

3 000

Бумага и расходные материалы

5 000

2 000

Оплата труда

68 090

14 690

Стоимость процесса, руб./мес.

603 090

519 690

Экономический эффект от внедрения как разница между стоимостью основного бизнес-процесса AS-IS и стоимостью основного бизнес-процесса TO-BE составляет: 82 745 руб./мес. = 591 755 руб./мес. – 509 010 руб./мес. С целью определения экономической эффективности внедрения информационной системы для реинжиниринга и автоматизации бизнес-процесса мониторинга состояния безопасности в организации были рассчитаны финансовые показатели NPV (Net Present Value) – чистый приведенный доход, IRR (Internal Rate of Return) – внутренняя норма доходности, DPP (Discounted Payback Period) – срок окупаемости с учетом дисконтирования. Сводная информация для расчета финансовых показателей приведена в табл. 42. Расчеты выполнены на основании общей системы налогообложения и ставки налога на прибыль в размере 20 %. Ставка дисконтирования выбрана в размере 15 % годовых из расчета безрисковой ставки 9 % годовых плюс 6 % годовых платы за риск. 142

143

Этап инвестиций

Экономический эффект от реализации проекта (разница между AS-IS и TO-BE) (снижение расходов)

2. Приток денежных средств

Накладные расходы

0

0

28 247

7 000

75 362

Материальные вложения

Нематериальные вложения

188 312

Расходы на оплату труда

1. Инвестиционные 298 921 и текущие вложения (отток денежных средств)

Показатель

83 400

83 400

1 136

10 000

0

7 570

18 706

1-й мес.

83 400

83 400

1 136

10 000

0

7 570

18 706

2-й мес.

4-й мес.

5-й мес.

6-й мес.

7-й мес.

8-й мес.

9-й мес.

10-й мес.

11-й мес.

12-й мес.

0

7 570 0

7 570 0 0

7 570 7 570 0

7 570

0

7 570

0

7 570

0

7 570

0

7 570

1 136

1 136

1 136 1 136

1 136

1 136

1 136

1 136

1 136

83 400 83 400 83 400 83 400 83 400 83 400 83 400 83 400 83 400 83 400

83 400 83 400 83 400 83 400 83 400 83 400 83 400 83 400 83 400 83 400

1 136

10 000 10 000 10 000 10 000 10 000 10 000 10 000 10 000 10 000 10 000

0

7 570

18 706 18 706 18 706 18 706 18 706 18 706 18 706 18 706 18 706 18 706

3-й мес.

Этап эксплуатации

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

Т а б л и ц а 42

144

1-й мес.

2-й мес.

3-й мес.

4-й мес.

5-й мес.

6-й мес.

7-й мес.

Этап эксплуатации 8-й мес.

9-й мес.

10-й мес.

11-й мес.

12-й мес.

т а б л. 42

59 353

64 695

0

0

59 353

64 695

0

0 4 910 12 939 12 939

59 353 54 848 47 482 47 482

64 695 59 784 51 756 51 756

0

0 24 551 64 695 64 695

47 482

51 756

12 939

64 695

47 482

51 756

12 939

64 695

47 482

51 756

12 939

64 695

47 482

51 756

12 939

64 695

47 482

51 756

12 939

64 695

–298 921 –239 568 –180 216 –120 863 –61 510 –6 662 40 820 88 302 135 784 183 267 230 749 278 231 325 713

59 353

5. Чистый –298 921 дисконтированный денежный поток по периодам (NCFi  K)

6. Чистый приведенный доход NPV в динамике

64 695

4. Чистый –298 921 денежный поток по периодам (NCFi)

0 0

0

0

Налог на прибыль по периодам

Прибыль по периодам

База для расчета –298 921 –234 227 –169 532 –104 838 –40 143 24 551 89 246 153 940 218 635 283 329 348 024 412 718 477 413 налога на прибыль на ра ст аю щим итогом

3. Прибыль и налоги

Показатель

Этап инвестиций

Окончание

Расчеты выполнены помесячно (период – 12 месяцев). Ставка дисконтирования: Rмес  12 1  Rгод – 1  1,1715 (%).

Коэффициент дисконтирования: 1-й год K дисконт 

1  0,8696; (1  Rмес. )12

2-й год K дисконт 

1  0, 7561. (1  Rмес. )24

Все показатели учтены без НДС. Амортизация во внимание не принималась. Расчеты произведены на основании общей системы налогообложения и ставки налога на прибыль в размере 20 %. Период окупаемости проекта (6 мес.) для расчета финансовых показателей и оценки экономической эффективности установлен в пределах Tмакс = 12 мес. Цена авансированного в проект капитала – СС (Cost of Capital) согласно экспертной оценке составляет 10 % годовых. На основании приведенных в табл. 42 данных вычислены значения финансовых показателей проекта внедрения информационной системы для автоматизации основного бизнес-процесса: 1) прогнозируемое значение показателя NPV за 12 месяцев – 325 713,20 руб.; 2) срок окупаемости с учетом дисконтирования DPP – 6 мес.; 3) внутренняя норма доходности IRR за 12 месяцев – 16,86 % годовых. Анализ прогнозируемых финансовых показателей (NPV > 0, DPP < Tмакс, IRR > СС) показал, что проект является экономически эффективным и гарантирует инвестору возвращение вложенных в него средств. Помимо экономического эффекта, строящегося на снижении расходов на обеспечение экономической (информационной) безопасности организации, целесообразно также оценить проект с точки зрения управления рисками. В ходе планирования должны быть проанализированы основные информационные активы организации, проведена стоимостная оценка и выявлены наиболее уязвимые активы на основании выполненного независимым экспертом исследования активов PrivacySafeguard Co. В табл. 43 и 44 отражены оценки уровней защищенности и возможного ущерба, нанесенного реализованной угрозой (здесь и далее все данные представлены в усредненном и обобщенном виде в силу необходимости соблюдения конфиденциальности результатов исследования). Разработанная информационная система снижает вероятность возникновения угрозы (атаки) и, соответственно, уменьшает стоимостную оценку рисков рассекречивания того или иного информационного актива. 145

Т а б л и ц а 43 Оценка уровней защищенности информационной системы Уровень защищенности Информация, которую необходимо защищать Высокий

Технологии работы (ноу-хау и секреты производства)

+

Конкурентные преимущества, которыми владеет организация

+

Средний

Новые продукты

+

Стратегические планы

+

Платежная информация

+

Движение денежных и материальных потоков, прочая финансовая информация

+

Клиенты, организации-партнеры, поставщики; контракты, договоры и т. д.

+

Персональные данные сотрудников

Низкий

+

Т а б л и ц а 44 Оценка уровней возможного ущерба организации Уровень возможного ущерба Информация, которую необходимо защищать Высокий

Технологии работы (ноу-хау и секреты производства)

+

Конкурентные преимущества, которыми владеет организация

+

Новые продукты

+

Стратегические планы

+

Средний

Платежная информация

+

Движение денежных и материальных потоков, прочая финансовая информация

+

Клиенты, организации-партнеры, поставщики; контракты, договоры и т. д.

+

Персональные данные сотрудников

Низкий

+

146

В табл. 45 применительно к модели AS-IS представлена примерная стоимостная оценка рисков на основании упомянутого выше исследования. Показатель EF (exposure factor) представляет собой процентную долю потерь, которые возникнут вследствие реализации характерной угрозы для определенного актива исходя из его стоимостной оценки. SLE (single loss expectance) – это потенциальная сумма (в денежном эквиваленте) ущерба для организации в результате единичного факта реализации соответствующей угрозы. Рассчитывается как произведение EF на стоимостную оценку актива. Т а б л и ц а 45 Стоимостная оценка рисков (модель AS-IS), руб. Информация, которую необходимо защищать

Риск

EF

SLE

Технологии работы (ноу-хау и секреты производства)

5 000 000,00

1

50 000 000,00

Конкурентные преимущества, которыми владеет организация

4 000 000,00

1

20 000 000,00

Новые продукты

3 000 000,00

1

20 000 000,00

Стратегические планы

3 000 000,00

0,5

15 000 000,00

Платежная информация

1 000 000,00

0,4

8 000 000,00

Движение денежных и материальных потоков, прочая финансовая информация

2 000 000,00

0,3

6 000 000,00

Клиенты, организации-партнеры, поставщики; контракты, договоры и т. д.

1 000 000,00

0,2

2 000 000,00

200 000,00

0,1

100 000,00

Персональные данные сотрудников

После внедрения информационной системы показатели стоимостной оценки информации (EF и SLE) остаются неизменными ввиду неизменности стоимости активов и субъективной оценки показателя EF, однако существенно снижаются вероятность успешной атаки и денежный эквивалент оценки риска (табл. 46). Экономический эффект с точки зрения снижения риска можно оценить при помощи расчета разницы между стоимостной оценкой рисков в соответствии с моделями AS-IS и TO-BE: Экономический эффект = 19 200 000,00 – 12 600 000,00 = = 6 600 000,00 (руб.).

147

Т а б л и ц а 46 Стоимостная оценка рисков (модель ТО-ВЕ), руб. Информация, которую необходимо защищать

Риск

EF

SLE

Технологии работы (ноу-хау и секреты производства)

2 500 000,00

1

50 000 000,00

Конкурентные преимущества, которыми владеет организация

1 000 000,00

1

20 000 000,00

Новые продукты

2 000 000,00

1

20 000 000,00

Стратегические планы

3 000 000,00

0,5

15 000 000,00

Платежная информация

1 000 000,00

0,4

8 000 000,00

Движение денежных и материальных потоков, прочая финансовая информация

2 000 000,00

0,3

6 000 000,00

Клиенты, организации-партнеры, поставщики; контракты, договоры и т. д.

1 000 000,00

0,2

2 000 000,00

100 000,00

0,1

100 000,00

Персональные данные сотрудников

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

148

СИТУАЦИОННЫЕ ЗАДАЧИ

Для решения ситуационных задач создается команда из 5–6 человек, каждый из которых берет на себя одну из перечисленных ниже ролей. 1. Бизнес-аналитик от организации. Знает архитектуру организации и всю ее внутреннюю «кухню», консультирует остальных членов команды по возникающим вопросам, формирует бизнес-требования, моделирует бизнес-процессы. 2. Менеджер проекта. Устанавливает критерии и ограничения проекта на разных этапах, составляет план проекта, рассчитывает экономическое обоснование проекта, определяет методологию разработки проекта и управления им, курирует плановую реализацию этапов проекта. 3. Системный аналитик (внешний). Знает особенности проектирования информационной системы, разрабатывает и документирует требования к ней. 4. Системный архитектор. Занимается проектированием информационной системы и разработкой функционального прототипа в соответствии с предъявленными требованиями. 5. Программист (не обязательно). Создает работающую информационную систему в соответствии с полученными требованиями. 6. Тестировщик. Проверяет на ошибки и соответствие требованиям полученный прототип и / или готовую информационную систему своей команды и чужих команд, заполняет чек-лист. В рамках учебного проекта занимается оформлением заданий в соответствии с требованиями нормоконтроля. Роль тестировщика может выполнять любой член команды, кроме программиста. Отметим, что формулировка приведенных в данном учебном пособии ситуационных задач охватывает лишь минимальное количество этапов всего жизненного цикла информационных систем, способных дать о них общее представление и образовать в итоге оптимально обоснованный и логичный ИТ-проект. И если при работе над задачами у вас в связи со спецификой ИТ-проекта возникнет необходимость в каких-то обоснованных изменениях, связанных с перечисленными выше допущениями, приветствуется обсуждение с преподавателем возможности внесения этих изменений в вашу работу.

149

Задача 1 Выбор организации, в которой будет внедряться ИТ-проект, для ее дальнейшего анализа, сбор информации. Формулировка проблемы, целей и бизнес-требований выбранной организации. Исполнители Бизнес-аналитик, менеджер проекта (для определения критериев и ограничений). Алгоритм решения задачи 1. Выберите организацию и (или) предметную область для дальнейшего анализа. Организация должна быть вам знакомой. Оптимальный вариант – вы в этой организации работали или работаете в настоящее время и хорошо знакомы с ее бизнес-процессами и с существующими проблемами. Также можно рассмотреть организации, в которых работают ваши родственники или знакомые, если они готовы представить, при необходимости, всю требующуюся информацию. 2. Подготовьте текстовое описание организации, где вкратце излагается следующая информация: сфера деятельности; миссия, цели, задачи; продукты / услуги; адрес; история и т. д. Источниками данной информации могут стать сотрудники организации, ее нормативные документы или корпоративный сайт. 3. Сформулируйте ту проблему организации, которая будет решаться путем разработки / внедрения информационной системы. Наиболее подходящими в рамках материалов данного учебного пособия проблемами являются: – низкая производительность труда; – низкое качество продуктов / услуг; – большие затраты на управление процессами в организации, частые ошибки исполнителей как следствие сложившейся системы управления; – потребность в продвижении продуктов / услуг; – необходимость повышения качества коммуникации с клиентами. Данные проблемы можно решить посредством разработки и внедрения различных информационных систем. Однако не каждое приложение разрабатывается для решения определенной проблемы, некоторые из них создаются для того, чтобы воспользоваться предоставляемыми рынком возможностями, даже если существование проблемы еще не очевидно. Таким образом, объектом исследования может стать и стартап, направленный на разработку новых ИТ-продуктов. В таком случае опишите направление деятельности стартапа и проблемы, которые призван решить новый ИТ-продукт для своих пользователей. 4. Постройте полную модель архитектуры выбранной организации, проведите анализ составляющих ее уровней. Определите подсистему, где нахо150

дится рассматриваемая проблема, выявите причины этой проблемы и следствия ее нерешения, определите возможное ИТ-решение. 5. Постройте модели бизнес-процессов AS-IS подсистемы, содержащей решаемую проблему организации. Важным условием является иллюстрация наличия проблемы в представленных моделях. 6. Определите всевозможные критерии и ограничения, накладываемые на проект, решающий выбранную проблему организации (некоторые возможные источники критериев и ограничений были представлены ранее в табл. 4). 7. С учетом анализа моделей AS-IS, критериев и ограничений проекта, а также с учетом возможных рисков предложите ИТ-решение для выбранной проблемы и заполните таблицу, аналогичную табл. 5. 8. Сформулируйте цель и бизнес-требование проекта. 9. Постройте модели бизнес-процессов TO-BE с учетом особенностей выбранного решения, бизнес-требований и цели ИТ-проекта. 10. Выберите и обоснуйте модель жизненного цикла для вашего ИТпроекта. 11. Письменный отчет о проделанной работе необходимо оформить в текстовом редакторе с обязательным указанием состава команды, участвовавшей в решении данной ситуационной задачи (роль каждого студента в команде, его фамилия, имя, отчество и номер академической группы).

Задача 2 Экономическое обоснование ИТ-проекта Исполнитель Менеджер проекта. Алгоритм решения задачи 1. Для определения жизненного цикла информационной системы постройте и заполните таблицу по образцу табл. 5. 2. Укажите условия до и после внедрения ИС, построив и заполнив таблицу по образцу табл. 3. 3. Если это применимо к вашему проекту, постройте график расходов до и после внедрения ИС. Определите точку равновесия. 4. Постройте график зависимости количества задач, исполняемых до и после внедрения ИС, от времени. 5. Рассчитайте ожидаемые доходы, расходы и прибыль. Постройте их графики. 6. Постройте график баланса организации. Определите сумму вложений, необходимых для реализации ИТ-проекта. 7. Сделайте вывод по поводу экономической целесообразности разработки ИС. 151

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

Задача 3 Анализ осуществимости разработки информационной системы Исполнители Внешний системный аналитик при участии и консультации бизнесаналитика. Алгоритм решения задачи 1. Выявите заинтересованных в ИТ-решении лиц, составьте и заполните таблицу по образцу табл. 12. 2. Определите первоначальные требования всех заинтересованных в ИС лиц. 3. Определите акторов для разрабатываемой ИС и требуемые ими сервисы. 4. Постройте модель границ ИС. 5. На основе полученных данных проведите анализ осуществимости выбранного ИТ-решения. 6. Письменный отчет о проделанной работе необходимо оформить в текстовом редакторе с обязательным указанием состава команды, участвовавшей в решении данной ситуационной задачи (роль каждого студента в команде, его фамилия, имя, отчество и номер академической группы). Задача 4 Проектирование системы, разработка функционального прототипа Исполнители Внешний системный аналитик при участии и консультации бизнесаналитика и менеджера проекта (выбор методологии). Алгоритм решения задачи 1. Дополните проект сценариями работы с системой (укажите все основные функции ИС, разработайте минимум по 1 сценарию для каждого пользователя). 2. Определите стек технологий для реализации ИС: язык программирования (могут использоваться отдельные компоненты разных языков программирования), библиотеки, CASE-средства и другие технологии. 3. Выберите методологию, в соответствии с которой будет осуществляться управление разработкой системы. 4. Создайте функциональный прототип системы в ForeUI или в другой системе прототипирования по разработанным ранее пользовательским сценариям. 152

5. Используя инструменты MS PowerPoint или Visio, разработайте модель информационных потоков, которые будут присутствовать в ИС, и опишите ее работу. Структура модели: входные данные  методы обработки  выходные данные. В модели должны быть указаны источники данных для ИС, хранения и (или) обработки данных, интерфейс. Так же опишите каждый компонент модели и их взаимодействие. 6. Письменный отчет о проделанной работе необходимо оформить в текстовом редакторе с обязательным указанием состава команды, участвовавшей в решении данной ситуационной задачи (роль каждого студента в команде, его фамилия, имя, отчество и номер академической группы).

Задача 5 Разработка функционального прототипа системы / кодирование системы Исполнитель Программист. Алгоритм решения задачи 1. Выберете язык программирования для реализации вашей ИС. Для этого необходимо выделить не менее пяти критериев для каждого языка программирования и провести их сравнительный анализ посредством построения и заполнения таблицы, пример которой приведен ниже (табл. 47). Обоснуйте свой выбор. 2. Если в команде есть опытный разработчик, дополните проект кодом исполнения одного или нескольких сценариев событий. Любое REST API, независимо от форматов обмена, должно соответствовать указанным ниже требованиям. Модель клиент-сервер. Разграничение потребностей является принципом, лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса клиента от потребностей сервера, хранящего данные, повышает переносимость кода клиентского интерфейса на другие платформы, а упрощение серверной части улучшает масштабируемость. Отсутствие хранения состояния. Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Состояние сессии при этом сохраняется на стороне клиента. Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например, в службу базы данных) для поддержания устойчивого состояния на период, скажем, установления аутентификации. Клиент инициирует отправку запросов, когда он готов (когда у него возникает необходимость) перейти в новое состояние. 153

Т а б л и ц а 47 Пример таблицы для оценки языка программирования GUI КроссПрос- (графический Графика Графика Спецплатфоринтерфейс (2D) (3D) тота процессор менность пользователя)

Скорость обработки

Читабельность

С

8

6

2

3

5

8

7

10

С++

8

6

3

4

6

8

7

7

С#

7

7

5

6

6

7

2

0

Java

6

7

6

7

7

6

10

0

Python

2

5

10

8

10

1

10

0

VB.net

6

10

8

10

5

2

2

0

Assembler

10

0

0

0

0

0

0

5

Язык

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

Задача 6 Тестирование функционального прототипа Исполнитель Тестировщик. 154

Алгоритм решения задачи 1. Выберите методики тестирования исходя из особенностей вашей информационной системы, а также предназначенные для использования нефункциональные тесты. 2. Проведите тестирование функционального прототипа системы на соответствие требованиям заказчика, заполняя в процессе тестирования чеклист. 3. Письменный отчет о проделанной работе необходимо оформить в текстовом редакторе с обязательным указанием состава команды, участвовавшей в решении данной ситуационной задачи (роль каждого студента в команде, его фамилия, имя, отчество и номер академической группы).

Задача 7 Формирование технических требований Исполнитель Тестировщик. Алгоритм решения задачи 1. Опишите системные клиентские и серверные требования. Пример требований Минимальные: – ОС: Windows XP 64bit (latest SP); – процессор: 2.2Ghz Dual Core; – оперативная память: 4 GB ОЗУ; – видеокарта: 1 GB Dedicated VRAM; – DirectX: версии 9.0c; – место на диске: 3 GB. Рекомендованные: – ОС: Windows 10; – процессор: 4Ghz Quad Core; – оперативная память: 8 GB ОЗУ; – видеокарта: 3 GB Dedicated VRAM; – DirectX: версии 11; – место на диске: 5 GB. 2. Проведите тестирование функционального прототипа системы другой команды на соответствие требованиям заказчика, заполняя в процессе тестирования чек-лист. 3. Письменный отчет о проделанной работе необходимо оформить в текстовом редакторе с обязательным указанием состава команды, участвовавшей в решении данной ситуационной задачи (роль каждого студента в команде, его фамилия, имя, отчество и номер академической группы). 155

ИНФОРМАЦИОННЫЕ РЕСУРСЫ, РЕКОМЕНДУЕМЫЕ К ИЗУЧЕНИЮ

Берг Д. Б. Управление жизненным циклом информационных систем : учебное пособие / Д. Б. Берг, О. М. Зверева, А. Ю. Вишнякова. – Екатеринбург : Изд-во Урал. ун-та, 2022. – 94 с. – ISBN 978-5-7996-3594-7. Вигерс К. Разработка требований к программному обеспечению / К. Вигерс, Дж. Битти ; [пер. с англ.]. – 3-е изд., доп. – Москва : Русская редакция ; СанктПетербург : БХВ-Петербург, 2014. – 736 с. – ISBN 978-5-7502-0433-5 (Русская редакция), ISBN 978-5-9775-3348-5 (БХВ-Петербург). Вишнякова А. Ю. Прикладной системный анализ в сфере ИТ: предварительное проектирование и разработка документ-концепции информационной системы : учебное пособие / А. Ю. Вишнякова, Д. Б. Берг ; научный редактор А. С. Кощеев. – Екатеринбург : Изд-во Урал. ун-та, 2020. – 179 с. – ISBN 978-5-7996-3086-7. Вишнякова А. Ю. Системный анализ и управление требованиями : дистанционный курс / А. Ю. Вишнякова // Система электронного обучения на платформе Гиперметод : портал. URL: https://learn.urfu.ru/subject/index/card/subject_id/3502 (дата обращения: 20.12.2022). Гагарина Л. Г. Технология разработки программного обеспечения : учебное пособие / Л. Г. Гагарина, Е. В. Кокорева, Б. Д. Виснадул ; под редакцией Л. Г. Гагариной. – Москва : Форум, 2009. – 399 с. – ISBN 978-5-8199-0342-1. Гниденко И. Г. Технология разработки программного обеспечения : учебное пособие / И. Г. Гниденко, Ф. Ф. Павлов, Д. Ю. Федоров. – 1-е изд. – Москва : Юрайт, 2017. – 235 с. – ISBN 978-5-534-05047-9. Голубева Т. Б. Основы моделирования и оптимизации процессов и систем сервиса : учебное пособие / Т. Б. Голубева. – Екатеринбург : Изд-во Урал. ун-та, 2017. – 108 с. – ISBN 978-5-7996-2109-4. Леффингуэлл Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход / Д. Леффингуэлл, Д. Уидриг. – Москва : Вильямс, 2002. – 448 с. – ISBN 5-8459-0275-4.

Учебное из да ние

Детков Александр Александрович Вишнякова Алина Юрьевна Тарасьев Александр Александрович

ЖИЗНЕННЫЙ ЦИКЛ ИНФОРМАЦИОННЫХ СИСТЕМ: ОТ ИДЕИ ДО ВНЕДРЕНИЯ Учебное пособие

Заведующий редакцией М. А. Овечкина Редактор Е. И. Маркина Корректор Е. И. Маркина Компьютерная верстка Г. Б. Головина

Подписано в печать 26.10.2023. Формат 70100/16. Бумага офсетная. Цифровая печать. Уч.-изд. л. 10,0. Усл. печ. л. 12,9. Тираж 30 экз. Заказ 147. Издательство Уральского университета. Редакционно-издательский отдел ИПЦ УрФУ 620083, Екатеринбург, ул. Тургенева, 4. Тел.: +7 (343) 389-94-79, 350-43-28 E-mail: [email protected] Отпечатано в Издательско-полиграфическом центре УрФУ 620083, Екатеринбург, ул. Тургенева, 4. Тел.: +7 (343) 358-93-06, 350-58-20, 350-90-13 Факс +7 (343) 358-93-06 http://print.urfu.ru