Текст
Уральский
федеральный
университет
имени первого Президента
России Б. Н. Ельцина
Институт экономики
и управления
А. А. ДЕТКОВ
А. Ю. ВИШНЯКОВА
А. А. ТАРАСЬЕВ
ЖИЗНЕННЫЙ ЦИКЛ
ИНФОРМАЦИОННЫХ СИСТЕМ:
ОТ ИДЕИ ДО ВНЕДРЕНИЯ
Учебное пособие
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
УРАЛЬСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ
ИМЕНИ ПЕРВОГО ПРЕЗИДЕНТА РОССИИ Б. Н. ЕЛЬЦИНА
А. А. Детков, А. Ю. Вишнякова, А. А. Тарасьев
ЖИЗНЕННЫЙ ЦИКЛ
ИНФОРМАЦИОННЫХ СИСТЕМ:
ОТ ИДЕИ ДО ВНЕДРЕНИЯ
Учебное пособие
Рекомендовано методическим советом
Уральского федерального университета
в качестве учебного пособия для студентов вуза, обучающихся
по направлению подготовки 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
ОТ АВТОРОВ
Глобальный процесс цифровизации рыночной экономики задает повы¬
шенные требования как к цифровой зрелости организации (компании, пред¬
приятия, учреждения и т. д.) и минимизации издержек производственной
и проектной деятельности, так и к уровню подготовки квалифицированных
кадров, привлекаемых к реализации задач на стыке современного развития
бизнеса и широкого использования информационных систем (ИС) и техноло¬
гий. При этом требуется эффективно управлять жизненным циклом инфор¬
мационных систем, внедрять их в производственные процессы и повышать
конкурентоспособность организаций.
В связи с этим возрастает актуальность подготовки специалистов в об¬
ласти постановки задач, проектирования информационных систем, управле¬
ния их жизненным циклом, владеющих ключевыми методами создания алго¬
ритмов анализа и построения ИС для реального сектора и навыками анализа
рыночной ситуации и внедрения цифровых продуктов в бизнесе. В представ¬
ленном учебном пособии приведена ключевая информация, необходимая
в процессе подготовки специалистов к работе на стыке бизнеса и инфор¬
мационных технологий, - описываются требования к информационной сис¬
теме на этапе предпроектного обследования, раскрываются вопросы проек¬
тирования, разработки, тестирования и ввода в эксплуатацию ИС с расшире¬
нием в виде методов и правил экономического обоснования эффективности
ИТ-проекта и анализа осуществимости его внедрения.
Авторами предлагается описание и на сквозном примере рассматривает¬
ся содержание этапов жизненного цикла разработки информационных сис¬
тем от возникновения идеи об их необходимости до момента ввода в эксплуа¬
тацию этих ИС, сервисов и приложений в рамках развития бизнес-систем.
Ориентировано данное учебное пособие на студентов, изучающих дис¬
циплины «Проектирование информационных систем» и «Жизненный цикл
информационных систем».
Также материалы этого учебного пособия будут полезны специалистам
в качестве справочной информации по применению методов системного ана¬
лиза в практической деятельности организаций в условиях цифровизации
процессов проектирования и внедрения современных информационных сис¬
тем. А приведенные в пособии примеры применения методов системного
анализа к решению прикладных производственных задач и предлагаемые
для самостоятельного решения ситуационные задачи позволят расширить
компетенции специалистов в области предпроектного обследования, разра¬
ботки и внедрения систем, сервисов и приложений, повышающих финан¬
совую эффективность организаций.
ВВЕДЕНИЕ
Современное состояние рынка информационных технологий позволяет
осуществить качественно новый переход к повышению уровня финансовой
отдачи в реальном секторе экономики благодаря эффективным системам
управления бизнес-процессами. В число ключевых условий успешной дея¬
тельности организации в настоящее время входят внедрение информацион¬
ных систем в бизнесе, проведение предпроектного обследования и примене¬
ние методов системного анализа как к секторам рынка, так и к системам ор¬
ганизаций. При этом требуется комплексное решение вопроса повышения
эффективности бизнес-структур посредством минимизации издержек, повы¬
шения производительности труда и уровня подготовки кадров в области
экономики, управления и развития информационных технологий, что позво¬
лит обеспечить переход к цифровой экономике. В связи с этим повышается
актуальность подготовки специалистов в области постановки задач проек¬
тирования, разработки и внедрения информационных систем управления
организацией, владеющих навыками анализа рыночной ситуации и включе¬
ния цифровых продуктов в бизнес-системы.
Информационная система - это комплекс инструментальных средств,
сервисов, методов, «информационных потоков», необходимых для реализа¬
ции деятельности организации.
Период времени от момента принятия решения о создании информа¬
ционной системы вплоть до ее полного изъятия из эксплуатации называет¬
ся жизненным циклом ИС.
ГОСТ Р 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.
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
О к о н ч а н и е т а б л. 1
№
п/п
Этап системного
подхода
Задачи этапа
Методы
7
Внедрение
решения
Подготовка к внедрению.
Внедрение решения и контроль
процесса внедрения.
Оценка эффективности
реализации и последствий
Методы экономического
анализа.
Морфологические методы.
Статистические методы
Не сложно заметить, что особое место в системе методов занимает
моделирование - метод познания, который заключается в представлении
предметов, систем, процессов и явлений в виде идеальных абстрактных об¬
разов - моделей и их исследовании.
Таким образом, результатом моделирования является модель - матери¬
альный или идеальный объект, замещающий исследуемую систему и адек¬
ватным образом отображающий ее существенные стороны. Модель объекта
(процесса, явления) отражает его свойства и связи между ними. Чем больше
свойств и связей воплощено в модели, тем ближе модель к реальному объек¬
ту. Учитываемые в модели свойства объекта (из огромного их числа) назы¬
ваются признаками, или характеристиками. Среди отражаемых в модели
признаков различают переменные и параметры.
Переменные - это признаки, которые могут иметь разные значения
и не влияют на характер модели. Признаки, оказывающие наиболее су¬
щественное влияние на поведение моделируемого объекта, называются
факторами. Качественная либо количественная характеристика перемен¬
ных осуществляется через показатели.
Взаимосвязь между переменными отражается через параметры - отно¬
сительно постоянные характеристики модели, изменение которых ведет
к изменению ее характера.
Существующие модели чрезвычайно разнообразны, и применяются
различные способы их классификации (табл. 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
Рис. 3. Стратегические цели и задачи УНИИФ на 2018-2021 годы
- увеличение числа патентов УНИИФ на инновационные разработки
на 10 % в период реализации стратегии;
- рост числа научных публикаций сотрудников УНИИФ в российских
и зарубежных изданиях на 30 % в период реализации стратегии.
Модель бизнес-стратегии УНИИФ представлена на рис. 4.
Анализ бизнес-стратегии УНИИФ показывает, что этот научно-исследова¬
тельский институт имеет грамотный план развития, включающий решение
актуальных проблем, направленных на совершенствование организации
противотуберкулезных мероприятий.
29
Стратегии
Проведение фундаментальных
исследований по поиску новых методов
лечения туберкулеза
Изготовление лекарственных средств,
их качественный и количественный
анализ, получение, хранение и отпуск
Содержание, разведение, подготовка
лабораторных животных для медико¬
биологических исследований
Приобретение нового
высокотехнологичного
хирургического оборудования
о
Обучение и повышение квалификации
сотрудников УНИИФ
Издание и распространение печатной
продукции с результатами научной
деятельности УНИИФ
Организация и проведение
конгрессов, съездов, конференций,
семинаров и выставок
Организация образовательной
деятельности по программам
послевузовского образования
Социальная
значимость
Финансовая
для населения
поддержка
со стороны
государства
Факторы успеха
Высокий
Наличие
уровень
профессионализма
сотрудников
высокотехнологичного
оборудования
для проведения
научно-технических
исследований
и лечения пациентов
Государственная
значимость
организации
Быстрое внедрение
и освоение
новых технологий
Качественный
и количественный анализ
новых технологий
персоналом
и лекарственных средств
Стратегические требования
Ежемесячный анализ деятельности
организации по оказанию
медицинской помощи населению
и отслеживание динамики числа
больных в регионе
Повышение уровня взаимодействия
между сотрудниками УНИИФ,
поощрение их участия
в научно-технических разработках,
конференциях и в написании
научных статей
Ключевые показатели эффективности
Уменьшение показателя смертности
населения от туберкулеза минимум на 2 %
и увеличение числа ремиссий на 40 %
в первые 2 года по результатам работы
Увеличение числа патентов УНИИФ
на инновационные разработки на 10 %
в период реализации стратегии
Рост числа научных публикаций
сотрудников УНИИФ в российских
и зарубежных изданиях на 30 %
в период реализации стратегии
Рис. 4. Бизнес-стратегия УНИИФ на 2018 год
Моделирование уровня бизнес-архитектуры
Бизнес-процессы делятся на 3 категории:
- процессы управления (совокупность отдельных видов деятельности, на¬
правленных на обеспечение функционирования и развития бизнеса в инте¬
ресах достижения стоящих перед ним целей);
- основные процессы (процессы, определяющие доходы организации,
то есть процессы, направленные на предоставление товаров или услуг, поз¬
воляющих получать прибыль);
- обеспечивающие процессы (вспомогательные бизнес-процессы, соз¬
дающие условия для выполнения основных процессов и фактически снаб¬
жающие ресурсами всю деятельность организации).
Бизнес-процессы управления УНИИФ таковы:
- стратегический менеджмент;
- финансовое планирование;
- организация и контроль основных процессов;
- организация и контроль обеспечивающих процессов;
- управление персоналом.
Основными бизнес-процессами УНИИФ являются:
- научно-исследовательская деятельность;
- контроль оборота наркотических и психотропных веществ;
- оказание населению специализированной медицинской помощи;
- проведение противоэпидемических мероприятий;
- издание и рассылка печатной продукции с описанием результатов научной
деятельности института;
- фармацевтическая деятельность;
- ветеринарная деятельность;
- создание информационных ресурсов по профилю;
- образовательная деятельность;
- заготовка, переработка, хранение донорской крови, обеспечение безопас¬
ности ее применения;
- техническое обслуживание оборудования ионизирующих излучений
и радиоизотопов короткого действия;
- деятельность, связанная с использованием возбудителей инфекционных
заболеваний;
- мониторинг распространения туберкулеза и сочетанных инфекций (ВИЧ,
гепатиты).
Обеспечивающие бизнес-процессы УНИИФ:
- административно-хозяйственное обеспечение;
- юридическое обеспечение;
- бухгалтерский и налоговый учет;
- управление персоналом;
- ИТ-обеспечение.
31
Бизнес-процессы УНИИФ направлены на выполнение следующих биз-
нес-функций:
- управление основной деятельностью организации (бизнес-процессы
управления);
- выполнение работ и оказание медицинских услуг (основные бизнес-
процессы);
- обеспечение функционирования организации (обеспечивающие бизнес-
процессы).
Все бизнес-процессы УНИИФ и соответствующие им бизнес-функции пред¬
ставлены на рис. 5.
Реализация стратегических целей обеспечивается соответствующими
бизнес-процессами. Не подкрепленную бизнес-процессом цель достичь не¬
возможно.
Матрица взаимосвязи стратегических целей УНИИФ и бизнес-процес-
сов представлена в табл. 6.
Как было отмечено ранее, основные бизнес-процессы УНИИФ направ¬
лены на предоставление товаров или услуг.
Институт оказывает услуги по 4 основным направлениям (рис. 6):
- медицинская деятельность;
- образовательная деятельность;
- организационно-методическая деятельность;
- фармакологическая деятельность.
Медицинская деятельность в УНИИФ подразумевает оказание населе¬
нию медицинских услуг по следующим основным направлениям:
- врачебные консультации;
- диагностика;
- терапия;
- хирургия.
Образовательная деятельность в учреждении ведется по таким програм¬
мам послевузовского образования, как:
- аспирантура «Фтизиатрия» (очная, заочная);
- ординатура «Фтизиатрия», «Торакальная хирургия»;
- повышение квалификации руководящих специалистов.
Организационно-методическая деятельность в УНИИФ включает:
- проведение научно-технических исследований по государственным
целевым программам;
- организацию конгрессов, съездов, конференций и семинаров;
- написание и публикацию научных статей;
- издание печатной продукции, содержащей материалы о научной дея¬
тельности сотрудников института.
32
Процессы управления
Стратегический
менеджмент
Организация
и контроль основных
процессов
Организация и контроль
обеспечивающих
процессов
Финансовое
планирование
Управление
персоналом
л
Основные процессы
Научно-
исследовательская
деятельность
Фармацевтическая
деятельность
Контроль
оборота
наркотических
средств
и психотропных
веществ
Оказание
специализи¬
рованной
медицинской
помощи
Проведение
санитарно-
гигиенических
и противо¬
эпидемических
мероприятий
Создание
информационных
ресурсов
по профилю
Ветеринарная
деятельность
Мониторинг
распространения
инфекций
Образовательная
деятельность
Заготовка,
переработка,
хранение
донорской
крови,
обеспечение
безопасности
ее применения
Издание
и распространение
печатной продукции
с описанием
результатов научной
деятельности
сотрудников
института
Техническое
обслуживание
оборудования
ионизирующих
излучений
и радиоизотопов
короткого
действия
Деятельность,
связанная
с использованием
возбудителей
инфекционных
заболеваний
Административно-
хозяйственное обеспечение
f
Обеспечивающие процессы
Юридическое обеспечение
Бухгалтерский и налоговый учет
Охрана и безопасность
ИТ-обеспечение
Рис. 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
Фрагмент матрицы распределения
№
п/п
Бизнес-процесс
Краткое описание
Директор
Заместитель директора
по экономическим
вопросам
1
Стратегический
менеджмент
Долгосрочное
планирование
деятельности
организации
+
+
2
Оказание
специализированной
медицинской
помощи
Оказание
специализированной
ко нсул ьтатив но -
диагностической
помощи
3
Управление
персоналом
Поиск и отбор
кандидатов, прием
на работу, увольнение
+
4
Бухгалтерский
и налоговый учет
Подготовка
бухгалтерской
и налоговой
отчетности
Таблица 7
ответственности в УНИИФ
Ответственный за процесс, должность
Главный бухгалтер
Заместитель директора
по медицинской части
Заместитель директора
по КЭР и ККМП
Заместитель директора
по ОМР
Начальник службы
кадров
Начальник
технического отдела
Заместитель директора
по хозяйственным
вопросам
Заведующий
лабораторией
информационного
обеспечения
и организации
противотуберкулезной
работы
+
+
+
+
+
+
+
+
+
+
+
+
№
п/п
Бизнес-процесс
Краткое описание
Директор
Заместитель директора
по экономическим
вопросам
5
Финансовое
планирование
Экономический анализ
хозяйственной деятельности,
учет экономических
показателей
+
+
6
Образовательная
деятельность
Организация
образовательной
деятельности института
7
Поддержка ИТ
Создание и поддержка
современной
ИТ-инфраструктуры
8
Административно-
хозяйственное
обеспечение
Техническое обслуживание
зданий, помещений,
оборудования и т. д.
9
Мониторинг
распространения
инфекций
Проведение мониторинга
распространения
туберкулеза и сочетанных
инфекций (ВИЧ, гепатиты)
Окончание табл. 7
Ответственный за процесс, должность
Главный бухгалтер
Заместитель директора
по медицинской части
Заместитель директора
по КЭР и ККМП
Заместитель директора
по ОМР
Начальник службы
кадров
Начальник
технического отдела
Заместитель директора
по хозяйственным
вопросам
Заведующий
лабораторией
информационного
обеспечения
и организации
противотуберкулезной
работы
+
+
+
+
Система Visocall IP предназначена для обеспечения внутреннего взаимо¬
действия между всеми сотрудниками института.
Базовый пакет приложений Microsoft Office (MS Word, MS Excel) ис¬
пользуется при работе с большинством электронных документов и при под¬
готовке печатной продукции о научной деятельности сотрудников УНИИФ.
С помощью программного продукта Microsoft Project в УНИИФ выполня¬
ется стратегическое планирование.
Федеральная электронная медицинская библиотека необходима для обес¬
печения всех направлений образовательной деятельности, которую ведет
данное учреждение.
Единая государственная информационная система в сфере здравоохране¬
ния используется сотрудниками УНИИФ при ведении большинства основных
бизнес-процессов, требующих применения специализированных программных
средств.
Для установления взаимосвязей между приложениями и их функциями
может быть построена соответствующая модель (рис. 8).
Для оценки качества автоматизации бизнес-процессов может быть по¬
строена матрица связей бизнес-процессов и приложений (табл. 8).
У каждого приложения имеются своя функция и свое целевое назначе¬
ние, а следовательно, есть и определенные категории пользователей, у ко¬
торых выполнение их должностных обязанностей непосредственно связано
с использованием конкретных программных продуктов. Продемонстриро¬
вать эти взаимосвязи помогает матрица связей приложений и специалистов
(табл. 9).
Анализ связей приложений и специалистов (см. табл. 9) позволил вы¬
явить в УНИИФ следующие проблемы:
1) институт собирает информацию из диспансеров для дальнейшей
аналитики, однако примерно половина диспансеров Приволжского и Ураль¬
ского федеральных округов не включены в единую базу данных, большая
часть первичной информации о случаях заболеваний поступает в УНИИФ
на бумажных носителях и вводится в базы сотрудниками этого учреждения
вручную;
2) отсутствует бизнес-процесс по оперативному контролю заболеваний,
текущий процесс мониторинга осуществляется ежеквартально и не влечет
оперативных решений и контроля над ситуацией.
Уровень ИТ-инфраструктуры
Для того чтобы деятельность УНИИФ была действительно эффектив¬
ной, в институте требуется наличие правильно организованной инфра¬
структуры информационных технологий. Функциональная и надежная
ИТ-инфраструктура играет важную роль в развитии любой организации
и является основой ее жизнедеятельности, а также дает серьезное преиму¬
щество перед конкурентами.
41
+-
Функции приложений
Рис. 8. Связь между приложениями УНИИФ и их функциями
Т а б л и ц а 8
Фрагмент матрицы связей бизнес-процессов и приложений УНИИФ
№
п/п
Бизнес-процесс
Краткое описание
Приложения
Microsoft Project
1С: Предприятие
Visocall IP
Федеральная электронная
медицинская библиотека
MS Word, MS Excel
Единая государственная
информационная система
в сфере здравоохранения
1
Стратегический
менеджмент
Долгосрочное планирование
деятельности организации
+
+
+
2
Оказание
специализированной
медицинской
помощи
Оказание специализирован¬
ной консультативно-диагнос¬
тической помощи
+
+
3
Управление
персоналом
Поиск и отбор кандидатов, при¬
ем на работу, координация ра¬
боты, увольнение
+
+
+
4
Бухгалтерский
и налоговый учет
Подготовка бухгалтерской
и налоговой отчетности
+
+
5
Финансовое
планирование
Экономический анализ хозяй¬
ственной деятельности, учет
экономических показателей
+
+
6
Образовательная
деятельность
Организация образователь¬
ной деятельности института
+
+
7
Поддержка ИТ
Создание и поддержка совре¬
менной ИТ-инфраструктуры
+
+
8
Административно¬
хозяйственное
обеспечение
Техническое обслуживание
зданий, помещений, обору¬
дования и т. д.
+
+
9
Мониторинг
распространения
инфекций
Сбор информации из дис¬
пансеров по заболеваемости,
изучение и анализ показателей
заболеваемости, отчетность,
проведение мониторинга рас¬
пространения туберкулеза
и сочетанных инфекций (ВИЧ,
гепатиты)
+
+
43
Т а б л и ц а 9
Фрагмент матрицы связей приложений и специалистов УНИИФ
№
п/п
Пользователь
(должность)
Краткое описание цели
использования приложения
Приложения
Microsoft Project
1С: Предприятие
Visocall IP
Федеральная электронная
медицинская библиотека
MS Word, MS Excel
Единая государственная
информационная система
в сфере здравоохранения
1
Директор
Стратегическое планирова¬
ние, контроль выполнения
медицинских целевых про¬
грамм, взаимодействие с под¬
чиненными
+
+
+
+
+
2
Заместитель
директора
по экономическим
вопросам
Финансовое планирование
и контроль за госфинансами,
выделенными на оказание
медицинской помощи и про¬
ведение исследовательской
работы, взаимодействие с ди¬
ректором и подчиненными
+
+
+
+
3
Главный бухгалтер
Ведение бухгалтерского и на¬
логового учета, взаимодей¬
ствие с директором и подчи¬
ненными
+
+
+
4
Заместитель
директора
по медицинской части
Организация, распределение
и контроль медицинской по¬
мощи, анализ результатов
+
+
+
5
Заместитель
директора
по КЭР и ККМП
Выполнение клинико-экс¬
пертных работ и контроль ка¬
чества медицинской помощи
+
+
+
6
Заместитель
директора по ОМР
Обеспечение, подготовка
и проведение образователь¬
ных программ
+
+
+
7
Начальник службы
кадров
Разработка кадровой поли¬
тики и кадровой стратегии,
осуществление работ по под¬
бору, отбору и расстановке
+
+
+
44
О к о н ч а н и е т а б л. 9
№
п/п
Пользователь
(должность)
Краткое описание цели
использования приложения
Приложения
Microsoft Project
1С: Предприятие
Visocall IP
Федеральная электронная
медицинская библиотека
MS Word, MS Excel
Единая государственная
информационная система
в сфере здравоохранения
кадров на основе оценки
личных и деловых качеств
работников, контроль пра¬
вильности их использования
в подразделениях
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
USED АТ:
AUTHOR: Tарасьев Александр Александрович
PROJECT: Анализ данных в УНИИФ (AS-IS)
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
02.052022
■
WORKING
READER
DATE
CONTEXT:
REV:
16.052022
DRAFT
TOP
RECOMMENDED
PUBLICATION
Документ
с описанием
существующих
проблем
Стандартные
требования
предприятия
Федеральный
закон
«О персональн ых
данных»
■4—
40
Список необходимых данных
Необходимость в сохранении здоровья населения
Документ со списком мероприятий для сохранения
здоровья населения
►
Медицинский персонал
NODE:
A-0
TITLE:
Анализ данных в УНИИФ (AS-IS)
NUMBER:
I
Рис. 10. IDEF0 «Анализ данных в УНИИФ (AS-IS)», нулевой уровень
USED АТ:
AUTHOR: Tарасьев Александр Александрович
PROJECT: Анализ данных в УНИИФ (AS-IS)
NOTES: 123456789 10
DATE: 03.052022
■
WORKING
READER
DATE
CONTEXT:
REV:
16.052018
DRAFT
RECOMMENDED
PUBLICATION
A-0
LZ1
о
NODE:
AO
TITLE:
Анализ данных в УНИИФ (AS-IS)
NUMBER:
Рис. 11. IDEF0 «Анализ данных в УНИИФ (AS-IS)», первый уровень
USED AT:
AUTHOR: ТарасьевАлександр Але1сандрович
PROJECT: &1ализ данных в УНИИФ (AS-IS)
NOTES: 123456789 10
DATE: 03.052022
REV: 16.052022
■
WORKING
READER
DATE
DRAFT
RECOMMENDED
PUBLIC AT ON
CONTEXT:
AD
Документе описанием
существующих проблем £
Структурирование информации
Собранные
документы
ч
7
Станда ртны е требован ия
предприятия
Структурированн ые
данные
5
Результаты
обработки
документов
Федеральный за юн
«О персональных данныг
«»j
Г
1 I
Медицинский £
персонал §
А2
Сопоставление и построение
зависимостей междуданными
Формулировка и запись
Документы с выводами,:$
6 полученным и н а ос но ве;<;:
обработанных данных £
TITLE:
Обработка данных
NUMBER:
NODE:
Рис. 12. DFD «Анализ данных в УНИИФ (AS-IS)», второй уровень
отыскивает все необходимые документы в архиве и составляет список не¬
достающей информации, после чего начинает поиск этих документов
по отделениям, лабораториям и кабинетам, при этом часто оказывается,
что какие-то документы утеряны, и требуется их восстановление.
Главной проблемой процесса обработки данных является его длитель¬
ность: медицинскому работнику необходимо прочитать и структурировать
большое количество документов разных типов, которые состоят из сплошного
текста и таблиц, а затем всю информацию сопоставить и сделать выводы
для принятия решения. Это занимает огромное количество времени и зачас¬
тую получается так, что пока медицинский работник данные анализировал,
они стали неактуальными, и полученные по ним выводы практически ли¬
шены смысла.
Таким образом, для автоматизации в УНИИФ бизнес-процесса анализа
данных, для повышения уровня организации противотуберкулезных меро¬
приятий и контроля распространения туберкулеза в регионе был запущен
ИТ-проект, целью которого являлись разработка и внедрение ГИС «Очаги тубер¬
кулеза». Выбор такого решения был обусловлен отсутствием на рынке готово¬
го приложения, дающего возможность решить поставленные в проекте задачи.
Проведенное предпроектное обследование позволило конкретизиро¬
вать рассматриваемую проблему (табл. 10).
Т а б л и ц а 10
Первоначальная постановка обнаруженной в УНИИФ
проблемы
№
п/п
Элемент
Описание
1
Проблема
Снижение эффективности стандартных мер по борьбе
с туберкулезом
2
Объект негативного
воздействия проблемы
Население ПФО и УрФО
3
Результат воздействия
Распространение туберкулеза в масштабах ПФО и УрФО
4
Способ решения
проблемы
Разработка комплексного решения для автоматизации
сбора и анализа данных со всех диспансеров - ГИС
«Очаги туберкулеза»
5
Последствия
предлагаемого
решения
Повышение уровня взаимодействия медицинских служб,
а также качества сбора и анализа данных, что позволит
добиться улучшения организации противотуберкулез¬
ных мероприятий и контроля распространения тубер¬
кулеза и существенно изменить эпидемиологическую
ситуацию в ПФО и УрФО, связанную с тяжелыми инфек¬
ционными заболеваниями, в лучшую сторону
52
Также было сформулировано бизнес-требование к решению рассмат¬
риваемой проблемы: разработка и внедрение в УНИИФ ГИС «Очаги тубер¬
кулеза» (ГИС ОТБ) должны замедлить распространение туберкулеза в ПФО
и УрФО и снизить смертность населения от данной инфекции минимум
на 2 % путем автоматизации процессов анализа данных и внедрения опе¬
ративного мониторинга и контроля заболеваемости в первые 2 года после
внедрения.
Выявление критериев и ограничений проекта
Перед началом разработки информационной системы необходимо опре¬
делить ограничения, в рамках которых будет реализован проект (табл. 11).
Т а б л и ц а 11
Ограничения ИТ-проекта разработки
ГИС «Очаги туберкулеза»
№
п/п
Источник
ограничений
Образцы вопросов для выявления ограничений
1
Экономический
Какие финансовые или бюджетные ограничения следует учесть?
Для разработки планируется использование средств феде¬
рального бюджета и частных инвестиций. Бюджет формирует¬
ся из реальной стоимости разработки ГИС.
Существуют ли соображения, касающиеся себестоимости
и ценообразования?
Себестоимость будет определяться исходя из цены аппарат¬
ной части и зарплат участников проекта.
Существуют ли вопросы лицензирования?
В проекте используются технологии Open source и другое свобод¬
но распространяемое программное обеспечение, соответственно
в этом проекте правовое поле не будет нарушено. Функциониро¬
вание ГИС ОТБ как государственного веб-сервиса будет осуществ¬
ляться на основе Федерального закона Российской Федерации
«Об организации предоставления государственных и муници¬
пальных услуг» от 27 июля 2010 года № 210-ФЗ. Коммерческое
лицензирование программного продукта не предусматрива¬
ется. Отдельные компоненты ГИС могут быть запатентованы
при выявлении в них объектов интеллектуальной собственности.
Существует ли проект информационной системы и какой экономи¬
ческий выигрыш он должен принести (увеличение прибыли в /
на сколько)?
Существенный экономический выигрыш состоит в экономии
средств федерального бюджета за счет снижения уровня заболе¬
ваемости, поскольку стоимость лечения одного пациента составляет
в среднем 1 миллион рублей
53
Пр о д о л ж е н и е т а б л. 11
№
п/п
Источник
ограничений
Образцы вопросов для выявления ограничений
2
Политический
Существуют ли внешние или внутренние политические вопросы,
влияющие на потенциальное решение о разработке системы?
Для внедрения ГИС ОТБ в ПФО и УрФО потребуется полити¬
ческая воля уровня министерств здравоохранения соответству¬
ющих субъектов РФ.
Существуют ли в УНИИФ проблемы в отношениях между под¬
разделениями?
Выявлена проблема несвоевременного и неполного обмена ин¬
формацией между медицинскими службами.
Существует ли проект информационной системы и какой
политический эффект он может оказать (снижение числа
конфликтов в / на сколько раз?)
Миссия реализации ГИС ОТБ - повышение качества жизни
граждан и снижение социальной напряженности
3
Технический
Существуют ли ограничения в выборе технологий?
В проекте не будут использоваться технологии некоторых
крупных компаний из недружественных стран ввиду их мало¬
предсказуемого поведения на рынке России.
Должны ли мы работать в рамках существующих платформ
или технологий?
Клиентская часть информационной системы будет реализова¬
на в виде веб-интерфейса, поэтому приложение - кроссплат-
форменное.
Запрещено ли использование любых новых технологий?
Будут использованы любые технологии Open 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
USED АТ:
AUTHOR: Тарасьев Александр Александрович
PROJECT: Анализ данных в УНИИФ
NOTES: 123456789 10
DATE: 02.05.2022
REV: 16.05.2022
| WORKING
READER
DATE
DRAFT
RECOMMENDED
PUBLICATION
CONTEXT:
Необходимость в сохранении здоровья населения
Ui
00
Данные ГИС ОТБ
Документ
с описанием
существующих
проблем
Стандартные
требования
предприятия
Федеральный закон
«О персональных
данных»
и
Ор.
о
Анализ данных в УНИИФ
(ТО-ВЕ)
Документ со списком мероприятий
для сохранения здоровья населения
►
ГИС ОТБ
Медицинский
персонал
NODE:
A-0
TITLE:
Анализ данных в УНИИФ (TO-BE)
NUMBER:
1
Рис. 13. IDEF0 «Анализ данных в УНИИФ (ТО-BE)», нулевой уровень
Ui
чо
US ED АТ:
AUTHOR: Тарасьев Александр Александрович
PROJECT: Анализ данных в УНИИФ
NOTES: 123456789 10
DATE: 05.03.2023
■
WORKING
READER
DATE
CONTEXT:
REV: 05.03.2023
DRAFT
RECOMMENDED
PUBLICATION
A-0
NODE:
A0
TITLE
Анализ данных в УНИИФ (TO-BE)
NUMBER:
Г
Рис. 14. IDEF0 «Анализ данных в УНИИФ (ТО-BE)», первый уровень
USED AT;
AUTHOR: Тарасьев Александр Александрович
PROJECT: Анализ данных в УН ИИФ
NOTES: 123456789 10
REV: 05.03.2023
DATE: 05.03.2023
■
WORKING
READER
DATE
DRAFT
RECOMMENDED
PU BLICATION
CONTEXT:
AO
Федеральный закон <
(О персональных данных»:-
о
Документ с описанием
существующих проблем
Стандартные
требования
предприятие
Сопоставление
7:
Отобран ные
данные
Обработанные
и визуализированные
дан ные
и визуализация данных
системой
’Гр"
NODE:
Структурированные
1ные
Автоматическое
структурирование данных
У
Формулировка
и запись выводов
ГИС ОТБ
2
Медицинский
персонал
TITLE:
Обработка данных
NUMBER:
7
Документ
с выводами,
полученными
на основе
обработанных
данных
1
A2
Рис. 15. DFD «Анализ данных в УНИИФ (ТО-BE)», второй уровень
средств этой же ГИС будут сопоставляться и визуализироваться, а затем вы¬
водиться на монитор медицинскому сотруднику института. Медсотрудник
должен иметь возможность изучить обработанные и удобно визуализированные
данные, а затем сформулировать и записать на их основе все необходимые
выводы для последующего принятия решения по существующей проблеме.
Функциональные требования к ГИС «Очаги туберкулеза»
1. Система должна предоставлять пользователям возможность масшта¬
бируемой навигации по картографическим объектам.
2. Пользователь должен иметь возможность оценить ситуацию с распро¬
странением туберкулеза:
- в интересующей области Российской Федерации (осуществить выбор
области, получить данные о количестве в ней районов и населенных пунктов,
о численности и плотности населения, об общем количестве очагов забо¬
левания и о количестве очагов по каждой группе);
- в интересующем районе (осуществить выбор района, получить дан¬
ные о численности в нем населения, о количестве очагов и показателе эпиде¬
миологической напряженности, о количестве очагов по каждой группе и про¬
центном отклонении от среднего показателя по области);
- по конкретной группе заболеваний (выбрать группу заболеваний, по¬
лучить список районов с данными о количестве в них очагов туберкулеза
конкретной группы и показателе эпидемиологической напряженности).
3. Пользователь должен иметь возможность оценить ситуацию с выпол¬
нением мероприятий по противодействию активному распространению ту¬
беркулеза конкретной группы в выбранном районе области, в населенном
пункте, по конкретному адресу: осуществить выбор группы туберкулеза,
увидеть дату назначения мероприятия, статус выполнения мероприятия,
причину невыполнения мероприятия.
Требования к интерфейсам пользователя и внешним интерфейсам
1. Система должна иметь векторный графический веб-интерфейс для мас¬
штабируемой навигации по картографическим объектам.
2. Переходы между уровнями федеральных округов, уровнями субъектов
Российской Федерации и уровнями районов должны реализовываться в гра¬
фическом интерфейсе путем плавной анимации.
3. Геоинформационная онлайн-система должна отображать индикатив¬
ную информацию об уровне эпидемиологической напряженности во всех
территориальных субъектах, перечисленных в пункте 2, а также в отдель¬
ных очагах заболевания.
4. В графическом интерфейсе должна быть отражена информация о коли¬
честве очагов в субъекте по каждой группе опасности, о количественном при¬
росте новых инфекционных очагов в днях и месяцах, а также об общем ко¬
личестве очагов и общей численности населения в субъекте.
61
5. Система должна обеспечивать подачу данных на графический интер¬
фейс в режиме реального времени и в этом же режиме пересчитывать пока¬
затель эпидемиологической напряженности.
6. Система должна отображать картографическую информацию и ин¬
формацию, указанную в пункте 4, согласно группам очагов опасности.
7. Клиентская часть системы должна быть оптимизирована для работы
на ЭВМ отдельных диспансеров.
8. Источником данных для системы должна являться база данных консо¬
лидированных показателей медицинской статистики 1С: Медицина.
Нефункциональные требования
Атрибуты качества:
1) время обновления данных в графическом интерфейсе системы долж¬
но составлять не более 5 000 миллисекунд;
2) время перехода интерфейса из одного состояния в другое не должно
превышать 1 000 миллисекунд;
3) система должна быть реализована только на технологиях Open 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/prikaz-
fstek-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-образная
а
&
Инкрементная
Быстрого
прототипирования
Эволюционная
1
Разрабатывается ли в проекте продукт
нового для организации направления?
Нет
Нет
Нет
Да
Да
Да
2
Будет ли проект являться расширением
существующей системы?
Да
Да
Да
Да
Нет
Нет
3
Будет ли проект крупно- или среднемас¬
штабным?
Нет
Нет
Нет
Да
Да
Да
4
Ожидается ли длительная эксплуатация
продукта?
Да
Да
Нет
Да
Нет
Да
5
Необходим ли высокий уровень надеж¬
ности продукта проекта?
Нет
Да
Нет
Да
Нет
Да
6
Предполагается ли эволюция продукта
проекта в течение его жизненного цикла?
Нет
Нет
Нет
Да
Да
Да
7
Велика ли вероятность изменения систе¬
мы (продукта) на этапе сопровождения?
Нет
Нет
Нет
Да
Да
Да
8
Является ли график сжатым?
Нет
Нет
Да
Да
Да
Да
9
Предполагается ли повторное исполь¬
зование компонентов?
Нет
Нет
Да
Да
Да
Да
10
Являются ли достаточными ресурсы
(время, деньги, инструменты, персонал)?
Нет
Нет
Нет
Нет
Да
Да
Следует отметить, что данная процедура, направленная на обоснован¬
ный выбор модели жизненного цикла программного обеспечения для ИТ-
проекта, применима для достаточно масштабных проектов по разра¬
ботке информационных систем. Ее использование для небольших проектов
может привести к чрезмерному увеличению графика проекта, дополнитель¬
ным затратам и дополнительным рискам.
70
Таким образом, руководитель проекта должен четко представлять себе
и масштаб проекта, и необходимость его классификации для выбора моде¬
ли жизненного цикла программного обеспечения в соответствии с критери¬
ями, предложенными SQI.
Общая модель информационной системы
Согласно общей теории систем любая система сводится к составляю¬
щим, указанным на рис. 16.
1
Внешняя среда
Вход
“
Процессы преобразования
Выход
i
L
L
L
к
Обратная связь
Рис. 16. Общая модель информационной системы
При разработке информационной системы построение ее модели ос¬
новывается на определении акторов. Определение акторов позволяет раз¬
делить изучаемую систему на два интересующих разработчиков класса:
- система;
- то, что взаимодействует с системой.
Такое деление дает возможно сть определить границы разрабатывае¬
мой информационной системы (рис. 17).
Ввод-
вывод
Пользователи
Рис.
Граница
системы
I '
Наше решение
I
I,
системы
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
74
Рис. 19. Блок-схема работы интерфейсов мониторинга
геоинформационной системы
75
Рис. 20. Алгоритм работы интерфейса ввода данных
и контроля мероприятий геоинформационной системы
76
Централизованная база данных
Данные ПО
>т- 1С: Медицина
Веб-интерфейс
СУБД
Дополнительный интерфейс
для ввода данных
Р
Клиентский интерфейс
ввода информации
по отдельному району
к
Рис. 21. Модель информационных потоков ГИС
«Очаги туберкулеза»
Централизованная база данных - основной внешний источник данных
информационной системы, реализованный на основе программного обеспе¬
чения 1С: Медицина.
Дополнительный интерфейс для ввода данных разрабатывается при не¬
обходимости ручного ввода данных участковыми врачами тех медицин¬
ских учреждений, где программное обеспечение 1С: Медицина еще не ис¬
пользуется.
Далее на основе выявленных ранее требований был разработан фукцио-
нальный прототип ГИС и отрисованы эскизы интерфейсов на примере Тю¬
менской области.
Первый интерфейс ГИС «Очаги туберкулеза» - «Эпидемиологическая
обстановка» (рис. 22) позволит медицинскому работнику увидеть и оценить
ситуацию с распространением туберкулеза в интересующей его области
Российской Федерации в целом. Здесь будет отражена вся необходимая
для этого информация: после выбора области пользователь может получить
данные о количестве в ней населенных пунктов, численности и плотности
населения, о количестве очагов заболевания в целом и отдельно по каждой
группе. Районы на карте области будут раскрашены в соответствии со шкалой
плотности очагов, которая представлена в левой части интерфейса, что поз¬
волит специалисту быстро визуально определить районы с наиболее тяже¬
лой обстановкой и обратить на них повышенное внимание медицинских
и социальных служб.
Полный функционал интерфейса «Эпидемиологическая обстановка»
(рис. 23) будет раскрываться при наведении курсора мыши на любой
из районов выбранной области, после чего медицинский работник получит
развернутую информацию, относящуюся исключительно к выбранному
77
ГИС ОТБ «Эпидемиологическая обстановка»
Тюменская область
Эпидемиологическая обстановка
Режим градации ТБО
<1
00
Количество очагов
в Тюменской области
I группа
II группа
III группа
IV группа
V группа
Итого
•
-194
•
-S06
0
-382
о
- 1256
0
-0
- 2338
Шкала плотности
очагов по районам
Тюменская область
- 1236
Населенных пунктов
Численность
населения
Плотность населения
Количество очагов
Количество очагов
на 10 000 населения
- 3,660,030
- 2.5чел/км2
- 2338
Рис. 22. Эскиз интерфейса «Эпидемиологическая обстановка»
на примере Тюменской области
ГИС ОТБ «Эпидемиологическая обстановка»
Тюменская область
Эпидемиологическая обстановка
Режим градации ТБО
<1
чо
Количество очагов
в Тюменской области
1
группа
•
-194
II
группа
•
-506
III
группа
О
-382
IV
группа
О
- 1256
V
группа
О
-0
Итого
- 2338
Шкала плотности
очагов по районам
- 17
- 8
- О
Уватский район
Населенных пунктов
Численность
населения
Плотность населения
Количество очагов
Количество очагов
на 10 000 населения
- 33
- 19,125
- 0.4чел/км2
- 18
- 9.41
Количество очагов по группам
на 10 000 населения, отклонения
от общего показателя по области
1 группа :
0.52
U -2%
0.53
II группа :
1.05
U -24%
1.38
III группа :
3.14
И +202%
1.04
IV группа :
4.71
ft +37%
3.43
V группа :
0.00
и 0%
0
Рис. 23. Эскиз интерфейса «Эпидемиологическая обстановка»
на примере Уватского района Тюменской области
району (показатель эпидемиологической напряженности, количество насе¬
ленных пунктов, численность населения, общее количество очагов, таблица
с количеством очагов по каждой группе и процентное отклонение от сред¬
него показателя по области). При этом во время работы специалиста с от¬
дельным районом остальные районы будут окрашены в нейтральный цвет,
чтобы не отвлекать пользователя от рассмотрения конкретной ситуации.
Второй интерфейс ГИС «Очаги туберкулеза» - «Режим градации тубер¬
кулезных очагов» (рис. 24) должен предоставлять медицинскому работни¬
ку возможность оценить ситуацию с распространением туберкулеза по кон¬
кретной группе данного заболевания. Для этого в нижней части интерфей¬
са будут расположены 5 кнопок, каждая из которых позволяет получить
информацию об определенной группе туберкулеза. При нажатии на любую
из этих кнопок карта полностью перекрашивается в соответствии со шка¬
лой плотности очагов для выбранной группы, а в правой части интерфейса
появляется таблица с информацией только по очагам соответствующей группы
заболевания. В этой таблице содержится список всех районов с отражением
для каждого из них количества очагов туберкулеза данной группы, а также
приводится показатель эпидемиологической напряженности.
Третий интерфейс ГИС «Очаги туберкулеза» - «Районная эпидемиологи¬
ческая обстановка» (рис. 25). Доступ к нему должен открываться при наве¬
дении курсора на один из районов области при работе в первом или вто¬
ром интерфейсе информационной системы. На следующем этапе должна
появиться увеличенная версия карты выбранного района с отмеченными
на ней населенными пунктами, которые раскрашены в соответствии с рас¬
положенной в левой части экрана шкалой плотности в них очагов. Работая
с данным интерфейсом, пользователь сможет детальнее изучить ситуацию
с распространением туберкулеза по конкретному интересующему его райо¬
ну, для этого здесь будет представлена вся необходимая информация (чис¬
ленность населения, количество очагов и показатель эпидемиологической
напряженности). Помимо этого для каждой группы заболевания будет пред¬
ставлена шкала, отражающая динамику выполнения мероприятий по про¬
тиводействию распространению туберкулеза данной группы в выбранном
районе.
Также функционал интерфейса «Районная эпидемиологическая обста¬
новка» (рис. 26) позволит специалисту при наведении курсора на любой
из населенных пунктов узнать его название и получить основную инфор¬
мацию о количестве очагов туберкулеза и динамике выполнения мероприя¬
тий по противодействию распространению данной патологии.
Заключительный интерфейс ГИС «Очаги туберкулеза» - «Контроль вы¬
полнения мероприятий» (рис. 27). Как следует из названия, он будет ис¬
пользоваться для того, чтобы специалисты сферы здравоохранения могли
80
ГИС ОТБ «Эпидемиологическая обстановка»
Тюменская область
00
Количество очагов
в Тюменской области
1
группа
194
II
группа
506
III
группа
382
IV
группа
1256
V
группа
0
Итого
2338
Шкала плотности
очагов по районам
- 17
-8
-О
Очаги ТБ I группы
Число
очагов
Показатель
город Тюмень
Тюменский район
54
30
0.73
2.54
город Ишим
город Тобольск
Ялуторовский район
Ишимский район
Исетский район
Вагайский район
Казанский район
Абатский район
Голышмановский район
Омутинский район
Ярковский район
Тобольский район
Заводоуковский район
Армизонский район
Бердюжский район
Уватский район
Викуловский район
Нижнетавдинский район
Сладковский район
Упоровский район
Сорокинский район
Юргинский район
Аромашевский район
21
16
11
11
9
7
7
7
5
5
4
3
1
1
1
1
О
О
О
О
О
О
О
3.22
1.56
2.02
3.68
3.51
3.36
3.20
4.06
1.92
2.68
1.71
1.42
0.21
1.07
0.92
0.52
О
О
О
О
О
О
О
8 8 8 8 8 8 8
Рис. 24. Эскиз интерфейса «Режим градации туберкулезных очагов»
ГИС ОТБ «Эпидемиологическая обстановка»
00
ьо
Тюменская область - Ярковский район
Тюменская область Эпидемиологическая обстановка
Контроль выполнения
мероприятий
ЙЬ Л
I
II
III
IV
V
Итого
Ярковскии район
Численность населения 23 324
Количество очагов : мероприятия
I группа
II группа
III группа
IV группа
V группа
Количество очагов
в Ярковском районе
группа - 4
группа - 7
группа - 11
группа - 8
группа - 1
- 31
Плотность очагов
Населенных пунктов
Очаги ТБ
Населенный пункт
Число
очагов
Показатель
Ярково
10
12.11
Дубровное
5
25.68
Новоалександровка
4
22.11
Покровское
4
21.99
Ста роа л екса нд ро в ка
3
17.08
Плеханово
2
15.40
Иевлево
2
11.54
Щетково
1
8.61
Рис. 25. Эскиз интерфейса «Районная эпидемиологическая обстановка»
на примере Ярковского района Тюменской области
ГИС ОТБ «Эпидемиологическая обстановка»
Тюменская область - Ярковский район
00
Тюменская область
Количество очагов
в Ярковском районе
I группа - 4
II группа - 7
III группа - 11
IV группа - 8
V группа - 1
Итого - 31
Плотность очагов
Населенных пунктов
15
8
О
Эпидемиологическая обстановка
Контроль выполнения
мероприятий
Иевлево
Численность населения - 1733
Количество очагов : мероприятия
I группа -О
II группа -1 Г-—
III группа-0 3
IV группа-1
V группа -О
Очаги ТБ
Населенный пункт
Число
очагов
Показатель
Ярково
10
12.11
Дубровное
5
25.68
Новоалександровка
4
22.11
Покровское
4
21.99
Староалександровка
3
17.08
Плеханово
2
15.40
Иевлево
2
11.54
Щетково
1
8.61
Рис. 26. Эскиз интерфейса «Районная эпидемиологическая обстановка»
на примере выбора населенного пункта Иевлево
Режим контроля ТБО Ярковского района ГИС ОТБ
(демоне грационные данные)
Эпидемиологическая обстановка
Список населенных пунктов
Тюменская область - Ярковский район
Общий прогресс выполнения
мероприятий по Ярковскому району
00
■4—
Населенный пункт
Число
очагов
Село Ярково
ю|
Село Дубровное
5
Село Покровское
>1
Село Новоалексан.
4
Село Староалексан.
II
Село 11евлево
2
Село Птеханово
1
Село Щетково
К1
Село Усть-Тавда
1
Село Свиты
1
Село Матмассы
|«1
Не выполненные
в срок мероприятия
Ожидание выполнения
мероприятия
Мероприятия,
выполненные в срок
Рис. 27. Эскиз интерфейса «Контроль выполнения мероприятий»
Режим контроля ТБО Ярковского района ГИС ОТБ
(демонстрационные данные)
Эпидемиологическая обстановка
Тюменская область - Ярковский район
Список населенных пунктов Список очагов
Состояние выполнения мероприятий
Общий прогресс выполнения
мероприятий по Ярковскому району
00
U1
Населенный пункт
Число
очагов
Село Ярково
ю|
Село Дубровное
5
Село Покровское
1
Село Новоалексан.
4
Село Староалексан.
|з|
Село I !евлево
2
Село Плеханово
2
Село Щетково
1
Село Усть-Тавда
1
Село Свиты
1
Село Матмассы
■1
Первичное обследование
очага
О
Первичное обследование
контактных лиц
Заполнение карты
эпидемиологического
обследвання
• 25.09.2017
Дата
назначения
19.09.2017
21.09.2017
23.09.2017
, Не выполненные
I I в срок мероприятия
Причины невыполнения
мероприятий
Ожидание выполнения
мероприятия
Мероприятия,
выполненные в срок
Рис. 28. Эскиз полного функционала интерфейса «Контроль выполнения мероприятий»
назначать и проведение мероприятий по противодействию распространению
туберкулеза для определенного района Российской Федерации, и контроли¬
ровать их выполнение. С этой целью здесь будет максимально удобно
визуализирована вся необходимая информация. При запуске интерфейса
перед пользователем откроется список населенных пунктов выбранного райо¬
на с числом очагов по каждому из них. При этом данные в строках отоб¬
разят динамику выполнения мероприятий в конкретном населенном пункте
согласно легенде, которая представлена в нижней части интерфейса. Помимо
этого справа будет помещена уменьшенная версия карты выбранного района
и отражена общая динамика выполнения мероприятий по противодействию
распространению туберкулеза в процентном соотношении.
Полный функционал интерфейса «Контроль выполнения мероприятий»
(рис. 28) будет раскрыт при нажатии на строку с указанием интересующе¬
го населенного пункта, после чего появится список очагов по конкретным
адресам, а при активации одного из приведенных адресов появится таблица,
содержащая информацию о выполнении мероприятий по данному адресу
(название мероприятия, дата его назначения и статус выполнения; при необ¬
ходимости можно узнать и причину невыполнения мероприятия). Таким об¬
разом, с помощью данного интерфейса пользователь в наглядном виде полу¬
чит всю информацию о выполнении мероприятий по противодействию рас¬
пространению туберкулеза в интересующем районе включая конкретные даты
и адреса.
Итак, полная и наглядная визуализация данных в ГИС «Очаги тубер¬
кулеза» позволит специалистам сферы здравоохранения осуществлять про¬
странственный анализ заболеваемости населения туберкулезом всех групп
на различных масштабных уровнях, от областей до конкретных населен¬
ных пунктов. Благодаря ГИС ОТБ медицинские работники в максимально
понятном и удобном виде получат всю необходимую информацию для свое¬
временного принятия эффективных мер по противодействию туберкулезу
посредством грамотного распределения ресурсов, назначения противоту¬
беркулезных мероприятий и контроля их выполнения, а также для усовер¬
шенствования организационной политики медицинских и социальных служб.
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.
subjects
РК
s id INTEGER
s_name TEXT
s useralias TEXT
hashes
PK
h id INTEGER
email TEXT
h time TEXT
hash TEXT
type TEXT
events
PK
e id INTEGER
e time INTEGER
s_td INTEGER
e name TEXT
thermo REAL
lmg TEXT
users
PK
u_id INTEGER
u name TEXT
password TEXT
email TEXT
role INTEGER
notification INTEGER
counter INTEGER
active INTEGER
Рис. 29. Физическая модель базы данных
Таблица hashes содержит следующие поля:
- email (сопоставляемый 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.
>
{...});
>
//
//
>
app.get('/events',
app.get("/events/data",
app.post("/events/delete",
app.post("/events/search",
EVENTS
loadUser, async function (req, res) {.})
loadUser, async function (req, res) {.});
(req, res) {.});
function (req, res)
async function
loadUser, async
app.post('/events', async
EVENTS
function (req,
res) {.});
app.get('/users',
app.get('/users/edit',
app.post('/users/edit',
app.get("/users/data",
app.post("/users/update"
app.get("/users/delete",
USERS
loadUser, async function (req, res) {.});
loadUser,
async
function
(req, res)
{.})
loadUser,
async
function
(req, res)
{.})
loadUser,
async
function
(req, res)
{.})
, loadUser,
async
function
(req, res)
{.})
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
Expresses - это минималистичный и гибкий веб-фреймворк для прило¬
жений 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:
const
const
const
const
const
true });
sqlite = require("sqlite");
path = require('path');
redisStorage = require('connect-redis')
redis = require('redis');
client = redis.createClient();
(session);
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) >= config.thermo) {
event = "high temp";
} else {
event = "event"
}
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 =
? AND time
await db.all("SELECT e_id FROM events WHERE =s_id
?
? 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
await db.run(
img) VALUES (?,
img_name]);
'status': '500
${s.stmt.lastID) with user
} catch (error) {
console.error(error);
res.json({ 'status'
});
}
}
let
e_name,
event,
res.json({
await
INSERT
INTO
for
temp
(let i= 0; i
let
WHERE u_id
?,
■ г
?, ?)
'mess':
events (s_id, time, termo,
time, thermo,
, [t.s_id,
г
${t.s_name)
'Succesfully
'
created event
});
'500', 'mess':
'Failed to
insert event'
db.al1('SELECT *
< temp.length;
await db.run('UPDATE users
= ?
', [temp[i].u_id]);
FROM users
i++) {
SET counter
');
counter +1
{
s
s
'
'
'
"
г
'
?
г
'
}
db.close();
});
Обеспечение безопасности приложения
Для того чтобы приложение было достаточно безопасным, требуется
наличие обеспечивающих это инструментов. Рассмотрим фрагмент кода
для отправки запроса на регистрацию нового пользователя. Как можно за¬
метить, в коде задана проверка на наличие используемого email в базе,
пользователь изначально создается со статусом «неактивен», и до подтверж¬
дения почтового адреса посредством пришедшего на указанный email письма
вход в систему будет невозможен. Ссылка подтверждения генерируется
при помощи модуля криптографии Crypto и является уникальной в преде¬
лах системы, а хэш хранится в базе всего сутки, в течение которых возможно
подтверждение.
app.post('/events', async function (req, res) {
let db = await sqlite.open('dev');
let username = req.body. username;
let password = req.body.newPassF5;
let email = req.body.email;
94
console.1og(req.body);
('SELECT *
FROM
users WHERE
email
let
= ?',
г
tmp = await db.get
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); // Ссылка на ре¬
гистрацию активна сутки
var hash = crypto.createHash( 'sha256" ).update(email).
update(time).digest('hex');
? ,
г
'
let s
INSERT
? ,
= = await
INTO hashes
, ?)
[email,
db.run('
(email, time,
hash, type) VAL-UES( ? ,
time,
hash,
String(hash),
username)
г
db.close();
console.log(s)
try {
mailer(email,
}
catch (error)
console.error(error);
res.json({
'status': '500', 'mess
Failed to send email
});
}
res.render('register', {
to
type])};
${email} '
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 WHERE u_id = ?
' , [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");
}
}
Для реализации системы уведомлений используются сессии. Условно
работу с сессиями можно разделить на две части: клиентскую и серверную.
Между сервером и клиентом существует соединение, поддерживаемое ком¬
бинацией функций 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 += '<li> <div> <span class= "el" on-
click="deleteElement(this)"> Обнаружена температура' '+ tmp.thermo +"
y "+ tmp.user + "</span> </div> </li>";
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({ server });
97
wss.on('connection', async function connection(ws) {
let db = await sqlite.open('dev');
let data = await db.all('SELECT * FROM events WHERE time BE¬
TWEEN ? 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 WHERE s_id =
? ', 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();
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 тестирование (Е2Е-тестирование). Это
тестирование позволяет проверить работу всей системы или приложения
с точки зрения пользователя от начала и до конца.
100
Е2Е-тестирование включает в себя проверку основных сценариев ис¬
пользования приложения - от взаимодействия пользователя с интерфейсом
до проверки корректности ответа сервера. Также при Е2Е-тестировании про¬
веряются функциональные возможности приложения, такие как формирова¬
ние отчетов, работа с базами данных и другие. Таким образом, E2E-тестиро-
вание можно рассматривать и как функциональное, и как интеграционное.
Тестирование системы. При этом тестировании вся система проверяет¬
ся на наличие ошибок и багов. Осуществляется такое тестирование путем
сопряжения аппаратных и программных компонентов всей системы, а за¬
тем выполняется ее проверка. Это тестирование является разновидностью
метода тестирования «черного ящика», где проверяются ожидаемые для поль¬
зователя условия работы программного обеспечения.
Приемочное тестирование. Это последний тест, проводящийся пе¬
ред передачей программного обеспечения клиенту. Он выполняется для того,
чтобы гарантировать, что разработанное программное обеспечение отвеча¬
ет всем требованиям заказчика. Существуют два типа приемосдаточных ис¬
пытаний: испытание, которое осуществляется членами команды разработ¬
чиков, известно как внутреннее приемочное тестирование (альфа-тестиро¬
вание), а испытание, которое проводится заказчиком, известно как внешнее
приемочное тестирование. Если тестирование проводится с помощью пред¬
полагаемых клиентов, то оно называется приемочными испытаниями кли¬
ента. Если тестирование проводится конечным пользователем программ¬
ного обеспечения, то оно называется приемочным тестированием (бета-
тестированием).
Основные тесты
Существует несколько основных тестов, которые формируют часть режи¬
ма тестирования программного обеспечения. Эти тесты обычно считаются
самодостаточными в поиске ошибок и багов во всей системе.
Тестирование методом «черного ящика». Тестирование методом «чер¬
ного ящика» осуществляется без каких-либо знаний внутренней работы сис¬
темы. Тестер будет стимулировать программное обеспечение для пользова¬
тельской среды, предоставляя различные входы и проверяя сгенерированные
выходы. Этот тест также известен как black-box-тестирование, closed-box-тес-
тирование или функциональное тестирование.
Тестирование методом «белого ящика». Тестирование методом «белого
ящика», в отличие от тестирования методом «черного ящика», учитывает
внутреннее функционирование и логику работы кода. Для выполнения этого
теста тестер должен знать код, чтобы точно определить ту его часть, где име¬
ются ошибки. Этот тест также известен как white-box-, open-box- или Glass¬
box-тестирование.
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
Рис. 30. Характеристика DAS-топологии
системы хранения данных
Система хранения данных топологии SAN (Storage Area Network) - от¬
дельная сеть для подключения внешних устройств хранения данных (дис¬
ковых массивов, ленточных библиотек, оптических накопителей) к серве¬
рам таким образом, чтобы операционная система распознала эти ресурсы
как локальные. Данное архитектурное решение может расширяться как вер¬
тикально (путем добавления дополнительных дисков и полок расширения
к единому дисковому хранилищу), так и горизонтально (с добавлением но¬
вых хранилищ в инфр аструктуру сети). В этом случае серверы получают
доступ к дисковым накопителям посредством сети SAN и не нагружают
локальную сеть.
112
Рис. 31. Характеристика NAS-топологии
системы хранения данных
Топология SAN также может быть реализована в указанных ниже то¬
пологиях, что обеспечивает их повышенную гибкость, надежность и произ¬
водительность:
- точка-точка (прямое подключение сервера к массиву дисков);
- петля с арбитражной логикой (далее - FC-AL);
- коммутируемое подключение (далее - FC-SW).
На рис. 32 указаны достоинства и недостатки использования SAN-
топологии и сферы ее применения.
В основе концепции SAN-топологии системы хранения данных лежит
возможность соединения любого сервера с любым устройством хранения
данных. Устройства соединяются по протоколу Fibre Channel, который вы¬
полняет транспортную функцию, используя медные или оптоволоконные сое¬
динения устройств. К составляющим SAN-топологии относятся:
- хост-адаптер шины (реализует стек протоколов Fibre Channel);
- ресурсы хранения данных (дисковые массивы, ленточные накопите¬
ли и библиотеки с интерфейсом Fibre Channel);
113
SAN
Достоинства
V
Применение
Высокая скорость работы,
низкая задержка
Гибкость
и масштабируемость
Хранение данных блоками
(как, например, для почтовой
базы Exchange)
Простое использование
кэширования данных
Универсальность (доступ
к данным может получить
сервер приложений
под управлением любой
операционной системы)
Использование
территориально разнесенных
устройств хранения
Высокая надежность обмена
данными и хранения данных
Организация удаленного
архивирования
и восстановления данных
без дополнительных затрат
Агрегирование каналов
Быстрое подключение
устройств
Централизованное
управление коммутацией
и логистикой данных
В случае
необходимости
создания среды
для большого
(неограниченного)
количества
гетерогенных
(с различными
операционными
системами)
клиентов и других
серверов, особенно
в больших
компаниях,
имеющих филиалы,
а также у фирм,
занимающихся
виртуализацией
Разгрузка подсети
от служебного трафика
Рис. 32. Характеристика
SAN-топологии системы
хранения данных
114
- инфраструктурные устройства (сетевое оборудование: коммутаторы,
концентраторы, маршрутизаторы Fibre Channel);
- программное обеспечение (поддерживает таблицу путей доступа
к устройствам и обеспечивает отключение путей в случае аварии, динами¬
ческое подключение новых путей и распределение нагрузки между ними).
Итак, в системах хранения концепция виртуализации может быть реали¬
зована на уровне внешней памяти при введении разнородных накопителей
(DAS и NAS) в единый пул, а также на уровне сетей хранения (SAN). Топо¬
логии DAS, NAS и SAN, появлявшиеся на рынке последовательно, отражают
эволюционирующие цепочки связей между приложениями, использующими
данные, и байтами на носителе, содержащем эти данные.
Сведения об информационной системе
и ее жизненном цикле
Лучшим способом претворения в жизнь концепции управления жизнен¬
ным циклом информации в рамках среднего бизнеса является организация
частного корпоративного облака в форме сетевых узлов NAS. Реализация,
например, облачного хранения данных осуществляется в соответствии с мо¬
делью жизненного цикла информационной системы. В табл. 25 указаны
действия, выполнявшиеся на каждом этапе, а также приведен прогноз даль¬
нейшего функционирования этой системы. Длительность каждого этапа
жизненного цикла ИС соответствует реальным датам работы, а их стои¬
мость (с учетом оплаты труда с начислениями) определена исходя из ре¬
альных затрат в совокупности.
Выделены две подсистемы облачного хранилища:
- NAS-узел - сервер, предоставляющий службы для хранения данных
другим устройствам в сети;
- графический интерфейс пользователя GUI (Graphical User Interface) -
средства для взаимодействия пользователя с устройством при помощи сис¬
темных объектов и функций в виде графических компонентов экрана.
Определение требований к системе
Для осуществления выбора оборудования и утилит важно определить
требования к информационной системе. На выполнение данного этапа ушло
6 рабочих дней (с 1 февраля до 8 февраля 2022 г.).
Пользователями облачного хранилища будут сотрудники отделов про¬
движения и технологического сопровождения. Использование хранилища
может потребоваться как в помещении (бизнес-процесс «Поиск потребите¬
лей в отраслевых институтах»), так и в полевых условиях (бизнес-процесс
«Контроль и поддержка окрасочных работ на объекте»), поэтому скорость
и качество интернет-соединения могут варьироваться. Доступ пользовате¬
лей к данным должен предусматриваться с различных устройств: телефонов
115
Таблица 25
Полная модель жизненного цикла информационной системы для организации
Компонент
модели
Определение
требований
к системе
Проектиро¬
вание
Разработка
Тестирование
Внедрение
Эксплуатация
и сопро¬
вождение
Вывод
из эксплуатации
Длительность
1.02.2022-
8.02.2022
9.02.2022-
21.02.2022
22.02.2022-
28.03.2022
28.03.2022-
4.04.2022
4.04.2022-
15.04.2022
15.04.2022-
15.04.2032
15.04.2032-
1.05.2032
Стоимость, руб.
19 385
34 570
114 888
12 580
30 285
TBD
TBD
Надсистема
Выявление
потребности
офиса
организации
в облачном
хранилище
Определение
целей, задач
и бюджетных
ограничений.
Определение
количества
пользователей.
Выбор
варианта NAS
и утилит.
Составление
сметы и плана-
графика
работ.
Составление
технического
задания
и согласование
его
с руководством
Выделение
денежных
средств
на покупку
оборудования
и разработку.
Извещение
будущих
пользователей
о планируемом
внедрении
Подгото¬
вительные
работы
по внедрению
ИС.
Публикация
и обновление
инструкций
Автоматизация
процесса
хранения
и передачи
данных
в организации.
Помощь
пользователям.
Оптимизация
бизнес-
процессов
Коренное
изменение
в функцио¬
нировании
организации.
Продажа
оборудования
117
Компонент
модели
Определение
требований
к системе
Проектиро¬
вание
Разработка
Система
(облачное
хранилище)
Безопасность
данных.
Скорость
передачи
данных.
Адаптивность
Написание
и согласование
технического
задания
в проектной
команде
Настройка
оборудования.
Оптимизация
облачной
среды.
Составление
инструкций
для поль¬
зователей
Подсистема 1
(сервер - NAS)
Требования
к NAS-узлу
(минимальное
количество
пользователей,
объем
используемого
ими трафика
и состояние
оборудования)
Подбор
вариантов
NAS и HDD
Покупка
«белого»
IP-адреса.
Инициа¬
лизация
и конфигу¬
рация
сервера.
Импорт
пользова¬
телей
и установка
прав доступа.
Настройка
Active
Directory.
Продолжение табл. 25
Тестирование
Внедрение
Эксплуатация
и сопро¬
вождение
Вывод
из эксплуатации
Ручное
и автомати¬
ческое
тестирование
Организация
инсталляции
и отладки
работы
программного
обеспечения
на устройствах
сотрудников
Выявление
и устранение
неполадок
в работе
программного
обеспечения.
Модернизация
хранилища
Прекращение
работы
системы
Тестирование
сетевого
оборудования.
Исправление
ошибок
Использование
полных
мощностей
оборудования
Расширение
дискового
пространства
Извлечение
данных с HDD
Окончание табл. 25
118
Компонент
модели
Определение
требований
к системе
Проектиро¬
вание
Разработка
Тестирование
Внедрение
Эксплуатация
и сопро¬
вождение
Вывод
из эксплуатации
Создание
частного
облака
QNAPcloud.
«Пробрасы¬
вайте
портов»
Подсистема 2
(пользова¬
тельский
интерфейс -
GUI)
Требования
к интерфейсу
(возраст
пользователей,
опыт
использования
облачных
данных
нт. п.)
Подбор
утилит
в соответствии
с бизнес-
требованиями
Установка
пользова¬
тельских
утилит
(в том числе
интеграция
хранилища
с Office).
Организация
рассылки
приглашений
для пользо¬
вателей
Тестирование
программного
обеспечения
и элементов
интерфейса.
Исправление
ошибок
Инсталляция
программного
обеспечения
и отладка его
работы
на устрой¬
ствах
сотрудников
Совершен¬
ствование
интерфейса
в соответ¬
ствии
с требова¬
ниями
пользователей
и новых
технологий
Удаление
программных
продуктов
Примечание. TBD (to be determined) будет определена позже; HDD (hard disk drine) - тип накопителя.
и планшетов (операционные системы 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 или Ш, объем которых может достигать 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 лет функционирования созданной облачной системы хранения
данных технологии могут поменяться, и эта система может утратить акту¬
альность, а действия по ее совершенствованию могут перестать окупаться.
В таком случае необходимо будет вывести систему из эксплуатации: из¬
влечь с жестких дисков данные и переместить их в новое оборудование.
После этого потребуется выставить на продажу оборудование, выведенное
из эксплуатации. На все это уйдет около полутора месяцев.
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 и TCO.
Системные методы оценки
Достойной альтернативой экономическим методам оценки являют¬
ся системные методы. В их основе лежит учет различных показателей,
что позволяет понять реальную пользу от программы в разных областях
деятельности конкретной организации. Рассмотрим главные системные ме¬
тоды оценки.
Метод 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 позволяет быстро оценить проект:
NP
SSR = x100%,
TIC
где NP - чистая прибыль за период; TIC - полные инвестиционные затраты.
Срок окупаемости вложенных денежных средств (PP). Данный кри¬
терий позволяет проанализировать, в течение какого периода времени бу¬
дут возвращены первоначальные инвестиции.
PP = I0/P,
где I0 - первоначальные инвестиции; P - чистый годовой поток денежных
средств от реализации проекта.
Чистая приведенная стоимость (Net Present Value, NPV). Обычно
этот показатель используют, чтобы понять, стоит ли вкладывать деньги
в проект. Иногда с его помощью рассчитывают финансовые характеристи¬
ки за определенный период времени.
132
NPV = ± -NCF. -1.
S(1 + >)'
0
где 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 (руб.).
Эта сумма и будет чистой стоимостью, приведенной за год. Поскольку
она отрицательная, проект считается убыточным в выбранном периоде.
Но это не значит, что вложения не окупятся, - просто нужно увеличить
временной отрезок и использовать формулу
NCF NCF NCF NCF
n>v . Nc . N-f I
(1 + i) (1 + i)2 (1 + i)3 (1 + i)4 0
С каждым годом коэффициент дисконтирования уменьшается, поэтому
его нужно возводить в степень. Если взять предыдущий пример, за 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=
ncf
(1 + IRR)
+ ncf2
(1 + IRR)2
+ NCF3 + NCF4
(1 + IRR)3 (1 + IRR)4
- I0 =0.
Рассчитать это арифметически не получится. В экономических учебни¬
ках описываются 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
Затраты на оплату труда на этапе эксплуатации
(ежемесячные)
Специалист
Трудо¬
затраты, ч
Ставка,
руб./ч
Затраты
на оплату
труда, руб.
Подготовка аналитических отчетов
Руководитель проекта
5
401
2 005
Организация взаимодействия заказчика и исполнителя по поддержке системы
Руководитель проекта
5
401
2 005
Техническое обеспечение работы компьютерной техники, сетевого оборудования,
резервирование данных, администрирование программного обеспечения
Разработчик
10
356
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
Таблица 42
Сводная информация для расчета финансовых показателей, руб.
Показатель
Этап
инвес¬
тиций
Этап эксплуатации
1-й
мес.
2-й
мес.
3-й
мес.
4-й
мес.
5-й
мес.
6-й
мес.
7-й
мес.
8-й
мес.
9-й
мес.
10-й
мес.
11-й
мес.
12-й
мес.
1. Инвестиционные
и текущие вложения
(отток денежных
средств)
298 921
18 706
18 706
18 706
18 706
18 706
18 706
18 706
18 706
18 706
18 706
18 706
18 706
Расходы
на оплату труда
188 312
7 570
7 570
7 570
7 570
7 570
7 570
7 570
7 570
7 570
7 570
7 570
7 570
Материальные
вложения
75 362
0
0
0
0
0
0
0
0
0
0
0
0
Нематериальные
вложения
7 000
10 000
10 000
10 000
10 000
10 000
10 000
10 000
10 000
10 000
10 000
10 000
10 000
Накладные
расходы
28 247
1 136
1 136
1 136
1 136
1 136
1 136
1 136
1 136
1 136
1 136
1 136
1 136
2. Приток
денежных средств
0
83 400
83 400
83 400
83 400
83 400
83 400
83 400
83 400
83 400
83 400
83 400
83 400
Экономический
эффект
от реализации
проекта(разница
между AS-IS
иТО-ВЕ)
(снижение
расходов)
0
83 400
83 400
83 400
83 400
83 400
83 400
83 400
83 400
83 400
83 400
83 400
83 400
144
Показатель
Этап
инвес¬
тиций
1-й
мес.
2-й
мес.
3-й
мес.
4-й
мес.
3. Прибыль
и налоги
База для расчета
налога
на прибыль
нарастающим
итогом
-298 921
-234 227
-169 532
-104 838
-40 143
Прибыль
по периодам
0
0
0
0
0
Налог
на прибыль
по периодам
0
0
0
0
0
4. Чистый
денежный поток
по периодам (NCFi)
-298 921
64 695
64 695
64 695
64 695
5. Чистый
дисконтированный
денежный поток
по периодам
(NCFi х К)
-298 921
59 353
59 353
59 353
59 353
6. Чистый
приведенный
доход NPV
в динамике
-298 921
-239 568
-180 216
-120 863
-61510
Окончание табл. 42
Этап эксплуатации
5-й
мес.
6-й
мес.
7-й
мес.
8-й
мес.
9-й
мес.
10-й
мес.
11-й
мес.
12-й
мес.
24 551
89 246
153 940
218 635
283 329
348 024
412 718
477 413
24 551
64 695
64 695
64 695
64 695
64 695
64 695
64 695
4 910
12 939
12 939
12 939
12 939
12 939
12 939
12 939
59 784
51756
51756
51756
51756
51756
51756
51756
54 848
47 482
47 482
47 482
47 482
47 482
47 482
47 482
-6 662
40 820
88 302
135 784
183 267
230 749
278 231
325 713
Расчеты выполнены помесячно (период - 12 месяцев). Ставка дискон-
тирования:
Rco = -1 = 1,1715(%).
Коэффициент дисконтирования:
1
(1 + RMcc)12
1-й год
дисконт
= 0,8696;
2-й год
дисконт
1
(1 + RMcc)24
= 0,7561.
Все показатели учтены без НДС. Амортизация во внимание не прини¬
малась. Расчеты произведены на основании общей системы налогообложения
и ставки налога на прибыль в размере 20 %.
Период окупаемости проекта (6 мес.) для расчета финансовых показа¬
телей и оценки экономической эффективности установлен в пределах
Тмакс = 12 мес. Цена авансированного в проект капитала - СС (Cost of Capital)
согласно экспертной оценке составляет 10 % годовых.
На основании приведенных в табл. 42 данных вычислены значения
финансовых показателей проекта внедрения информационной системы
для автоматизации основного бизнес-процесса:
1) прогнозируемое значение показателя NPV за 12 месяцев - 325 713,20 руб.;
2) срок окупаемости с учетом дисконтирования DPP - 6 мес.;
3) внутренняя норма доходности IRR за 12 месяцев - 16,86 % годовых.
Анализ прогнозируемых финансовых показателей (NPV > 0, DPP < Тмакс,
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-систем.
СИТУАЦИОННЫЕ ЗАДАЧИ
Для решения ситуационных задач создается команда из 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. Письменный отчет о проделанной работе необходимо оформить
в текстовом редакторе с обязательным указанием состава команды, участ¬
вовавшей в решении данной ситуационной задачи (роль каждого студента
в команде, его фамилия, имя, отчество и номер академической группы).
ИНФОРМАЦИОННЫЕ РЕСУРСЫ,
РЕКОМЕНДУЕМЫЕ К ИЗУЧЕНИЮ
Берг Д. Б. Управление жизненным циклом информационных систем : учебное
пособие / Д. Б. Берг, О. М. Зверева, А. Ю. Вишнякова. - Екатеринбург : Изд-во Урал.
ун-та, 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. Формат 70x100/16.
Бумага офсетная. Цифровая печать.
Уч.-изд. л. 10,0. Усл. печ. л. 12,9. Тираж 30 экз. Заказ 147.
Издательство Уральского университета.
Редакционно-издательский отдел ИПЦ УрФУ
620083, Екатеринбург, ул. Тургенева, 4.
Тел.: +7 (343) 389-94-79, 350-43-28
E-mail: rio.marina.ovechkina@mail.ru
Отпечатано в Издательско-полиграфическом центре УрФУ
620083, Екатеринбург, ул. Тургенева, 4.
Тел.: +7 (343) 358-93-06, 350-58-20, 350-90-13
Факс +7 (343) 358-93-06
http://print.urfu.ru
Для заметок
Для заметок