96
update(model: file_data): file_data;
# Удаление файла по идентификатору редакции redaction_id
delete(redaction_id: string): bool;
# Массовое удаление
delete(redaction_ids: list<string>): list<string>;
}
Сам микро сервис разворачивается в отдельном процессе «Attachments»
со своей базой данных. Для удобной работы с микро сервисом реализуется
следующая схема взаимодействия модулей.
Рис. 23. Схема взаимодействия модулей
Соответствующий список модулей, предоставляемый микросервисом
«Attachments»:
1. Attachments – базовый интерфейсный модуль. Содержит описание всех
djinni моделей и CRUD интерфейсов, а также
сериализаторы/десериализаторы для djinni моделей для работы с базой
данных и передачей моделей между процессами через RPC вызовы.
2. AttachmentsStub – модуль, располагаемый в прикладном процессе.
Содержит имплементации CRUD интерфейсов «AttachmentStub» и
«FileStub», которые перенаправляют все исполнение в процесс
«Attachments». Сами имплементации возвращаются прикладному
программисту через Instance() соответствующих базовых абстрактных
классов. Пример метода в «AttachmentStub».
97
Рис. 24 Пример метода
3. AttachmentsAPI – модуль с базовыми API методами бизнес-логики для
работы с микро сервисом. Располагается как в прикладном процессе, так
и в процессе «Attachments», поэтому методы можно звать без указания
endpoint из прикладного процесса, а интерфейсные компоненты сервиса
«Docview» могут, как и прежде получать данные по пути
«attachments/service».
4. AttachmentsProxy – служебный приемный модуль, располагаемый в
процессе «Attachments». Содержит RPC методы, которые вызываются в
модуле «AttachmentsStub» из прикладного процесса. Сами RPC методы
перенаправляют исполнение в модуль «AttachmentsImpl».
5. AttachmentsImpl – рабочий модуль со всеми имплементациями CRUD
интерфейсов. Именно в классах «AttachmentImpl» и «FileImpl»
происходит вся обработка данных по вложениям.
При описанном выше подходе весь код работы с микро сервисом «Attachments»
сводится к следующим вызовам без указания endpoint процесса и с единым
интерфейсом.
Рис. 25 Код работы с микро сервисом «Attachments»
Подробное описание архитектуры. По сути максимально подробно, со схемами,
описать то, что было написано в разделе про общую архитектуру системы.
98
Раздел нужен для программистов, чтобы все понимали, что они должны будут
написать и как это должно работать.
Cхема архитектуры продукта должна давать стороннему разработчику или
новичку в вашей команде возможность быстро понять концептуальные
алгоритмы, как и с чем ваш сервис работает.
Если в рамках данного функционала был создан новый сайт, укажите это в
данном разделе, дайте ссылку на него и опишите кратко его назначение.
Рисунок 26.Схема архитектуры.
Ниже описаны основные принципы описания архитектуры продукта.
Связь от инициатора
Стрелочки всегда должны идти от инициатора процесса - то есть «кто-> кого
зовет». Поэтому все «двусторонние» стрелочки сразу вызывают вопросы и их
лучше не использовать.
При этом вариант «туда - мы позвали другой сервис по HTTP, обратно - он нам
отдал ответ» мы рассматриваем как однонаправленное взаимодействие,
99
поскольку «сам» сторонний сервис нас не звал, и без нас ничего бы
самостоятельно не делал.
Фактически, единственным вариантом двунаправленного взаимодействия
является какой-то асинхронный обмен данными.
Конечные точки
Не нужно рисовать несколько стрелок, приходящих в одну точку, т.к. связь в
таком случае непонятна.
Группировка
Для лучшего понимания схемы, на ней можно выделить группировкой
некоторые сущности: набор близких по функционалу сервисов;
расположение этих сервисов (логическое - относительно связи с другими
сервисами, например, основным, или физическое - у клиента/в нашем ЦОДе);
группу однотипных БД.
Декомпозиция на подсистемы и их взаимодействие
Для подсистемы продукта раздел не заполняется.
Картинка и несколько абзацев текста с пояснением, из каких модулей состоит
система. Концептуально в кубиках – какие есть подсистемы/сервисы и как они
взаимодействуют.
Модули, их зависимости
Указывается, из каких модулей состоит продукт/подсистема продукта, от каких
других модулей он/она зависит.
Репозитории GIT
Указывается, в каких репозиториях размещен продукт/подсистема продукта.
Если у продукта/подсистемы есть зеркало на github, это тоже должно быть
указано.
Диаграмма классов
Раздел необязательный, добавляется при необходимости. Диаграмма рисуется
на языке UML, используя Draw io.
По диаграмме классов не нужно описывать все досконально (если вы, конечно,
100
не практикуете DDD, и у вас используется ORM). Достаточно описать самые
основные классы и структуры, показать, где композиция, а где наследование.
Показать какие шаблоны проектирования используются. Следует иметь в виду,
что нужно описать эту часть отдельно по frontend и отдельно по backend.
Архитектура интерфейса
Если на участке есть богатый интерфейс, обязательно описываем его
архитектуру в одноименном разделе.
Декомпозиция интерфейса
Все основные окна, которые задействованы в вашем проекте, должны быть
декомпозированы на компоненты, и описано взаимодействие этих компонентов
между собой.
101
Рисунок 27. Декомпозиция интерфейса вкладки «Запросы»
Дополнительные компоненты
Укажите, какие компоненты были дописаны плюсом к платформе.
Алгоритмы построения страницы
Кратко опишите, что строится на сервере, что на клиенте и почему.
Особенности предварительной загрузки страниц: укажите, есть ли
«прелоадинг» на страницах и обозначьте, на каких именно он есть.
Алгоритм загрузки реестров
Обозначьте, какие данные откуда грузятся: какие «прилетают» сразу, а какие
грузятся динамически и почему.
Алгоритмы подгрузки данных на панель
Кратко опишите, что берется из record-set, а что запрашивается из облака.
Укажите, какие данные грузятся при нажатии тех или иных кнопок/выборе
фильтров в интерфейсе.
102
3. Обоснование экономической эффективности проекта
3.1. Выбор и обоснование методики расчёта экономической
эффективности
Под понятием «оценка экономической эффективности ИС» понимается
процесс, включающий в себя понимание, определение и измерение того,
насколько полезным в экономическом плане было внедрение информационной
системы на предприятии. При этом экономическая полезность рассматривается
обычно как денежный эквивалент того, насколько изменились доходы/расходы
предприятия в результате инвестирования в ИС.
Под методом оценки эффективности ИС подразумевается способ или
набор средств проведения полной оценки ИС.
Функционирование предприятия в рыночной среде требует анализа
экономических последствий, а также оценки экономической эффективности
того или иного шага преобразования системы управления предприятием.
Оценка экономической эффективности ИС – это сложная и трудоемкая
работа, требующая не только технических, но и экономических навыков.
Сочетание этих составляющих приводит к достоверному результату
проводимого анализа.
Продвижение на рынке ИС в условиях современной конкуренции
невозможно без предоставления результатов оценки ожидаемой эффективности
системы. Кроме того, существующая статистическая оценка успешности
внедрения систем управления предприятием характеризуется неудачей
внедрения от 40 до 70 % случаев.
Процесс соизмерения затрат и достигаемого за их счет эффекта должен
быть проводиться на протяжении всего этапа разработки и внедрения проекта,
результат которой способен повлиять на дальнейшее продолжение проекта.
Существуют следующие этапы оценки экономической эффективности
информационной системы:
103
− традиционная оценка эффективности как соотношение затрат и
результатов;
− расчет совокупной стоимости владения информационной системой;
− оценка внедрения ИС как инвестиционного проекта;
− разработка сбалансированной системы показателей для оценки
экономического эффекта;
Оценка эффективности проектов независимо от технических,
технологических, финансовых, отраслевых или региональных особенностей
осуществляется на основе единых принципов. К ним относятся:
− рассмотрение проекта на протяжении всего жизненного цикла;
− моделирование денежных потоков;
− сопоставимость условий сравнения различных проектов;
− положительность и максимум эффекта;
− учет фактора времени;
− учет только предстоящих в ходе осуществления проекта затрат и
поступлений;
− учет всех наиболее существенных последствий проекта;
− учет наличия разных участников проекта;
− многоэтапность оценки;
− учет влияния на эффективность инвестиционного проекта;
− учет влияния инфляции;
− учет влияния неопределенностей и рисков.
Показатели коммерческой эффективности проекта в целом отражают
финансовые последствия внедрения информационной системы. В качестве
основных показателей для расчета коммерческой эффективности проекта
рекомендуется использовать следующие:
− чистый доход;
− чистый дисконтированный доход;
104
− внутренняя норма доходности;
− индексы доходности затрат и инвестиций;
− срок окупаемости.
Таким образом, исходя из всего выше сказанного, можно сделать вывод,
что процесс оценки экономической эффективности информационных систем
сложен и неоднозначен. В рассматриваемом случае, так как система не
планируется к продаже, а будет внедрена только на одном предприятии,
необходимо рассчитать экономическую эффективность исходя из снижения
издержек на производственную деятельность.
При расчете экономической эффективности будет проведено сравнение
результатов обработки информации при существующей организации бизнес-
процессов и после внедрения разрабатываемой информационной системы.
Прямая эффективность машинной обработки информации представлена в
показателе снижения экономических стоимостных затрат на обработку
информации. При оценке прямой эффективности в стоимостных единицах
измерения рассчитываются две группы показателей – показатель снижения
трудовых затрат и показатель снижения стоимостных затрат.
При расчете изменения трудовых затрат на обработку информации
используется следующая система показателей:
1. Абсолютный показатель снижения трудовых затрат на обработку
информации
Т=Т
0
-Т
1
(1)
где Т
0
– годовая трудоемкость обработки информации при базисном
варианте;
Т
1
– годовая стоимость обработки информации при проектируемом
варианте.
2. Коэффициент снижения трудовых затрат
105
K
т
=(Т/Т
0
)*100 (%) (2)
3. Индекс снижения трудовых затрат, который показывает рост
производительности труда при обработке информации.
Y
т
=Т
0
/Т
1в
(3)
К стоимостным показателям относятся: абсолютное снижение
стоимостных затрат (C), коэффициент относительного снижения стоимостных
затрат (К
C
) индекс снижения стоимостных затрат (Y
C
):
1. Показатель снижения стоимостных затрат
С=С
0
-С
1
(4)
где С
0
– годовая стоимость обработки информации при базисном
варианте;
С
1
– годовая стоимость обработки информации при проектируемом
варианте.
2. Коэффициент эффективности по затратам:
K
c
=(С/С
0
)*100 (%) (5)
3. Индекс изменения стоимостных затрат
Y
c
=С
0
/С
1
(6)