ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт

154-пп от 21.03.2021 – об автоматизированной системе управления городскими финансами города москвы – электронная москва

1. Утвердить Положение об автоматизированной системе управления городскими финансами города Москвы (далее – АСУ ГФ) согласно приложению к настоящему постановлению.

2. Установить, что:

Мэр Москвы

С.С. Собянин

Приложение

к постановлению Правительства

Москвы

от 21 марта 2021 г. N 154-ПП

ПОЛОЖЕНИЕ

ОБ АВТОМАТИЗИРОВАННОЙ СИСТЕМЕ УПРАВЛЕНИЯ ГОРОДСКИМИ

ФИНАНСАМИ ГОРОДА МОСКВЫ

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

3. АСУ ГФ является собственностью города Москвы.

4. Целями использования АСУ ГФ являются:

4.1. Повышение качества управления финансами и планирования в городе Москве.

4.3. Обеспечение прозрачности и открытости информации о бюджете города Москвы, государственных программах города Москвы и государственном долге города Москвы.

5. Основными функциями АСУ ГФ являются:

5.1. Технологическое и информационное обеспечение процесса планирования бюджета города Москвы.

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

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

5.4. Обеспечение процесса формирования и ведения сводной бюджетной росписи, бюджетных росписей главных распорядителей бюджетных средств, а также формирования реестра расходных обязательств города Москвы, обоснования бюджетных ассигнований с помощью программных и аппаратных средств АСУ ГФ.

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

5.6. Обеспечение мониторинга государственного долга города Москвы, мониторинга динамики основных показателей бюджета города Москвы, а также мониторинга и анализа исполнения бюджета города Москвы с помощью программных и аппаратных средств АСУ ГФ.

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

5.8. Централизованное хранение информации о пользователях АСУ ГФ и истории предоставления им доступа к электронным сервисам.

5.9. Защита передаваемой информации от несанкционированного доступа, искажения или блокирования с момента поступления указанной информации в АСУ ГФ.

6. АСУ ГФ включает в себя следующие подсистемы:

6.1. Подсистема формирования проекта бюджета по расходам в программном представлении.

6.2. Подсистема формирования и доведения государственных заданий, расчета объемов финансирования государственных заданий.

6.3. Подсистема сбора и актуализации данных.

6.4. Подсистема составления и ведения сводной бюджетной росписи бюджета города Москвы, бюджетных росписей главных распорядителей бюджетных средств.

6.5. Подсистема мониторинга подготовки и реализации государственных программ города Москвы.

6.6. Подсистема “Плановый и уточненный реестр расходных обязательств города Москвы”.

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

6.8. Подсистема “Свод по сети, штатам и контингентам получателей бюджетных средств”.

6.9. Подсистема “Открытый бюджет”.

10. Оператор АСУ ГФ:

10.4. Обеспечивает целостность и неизменность информации с момента ее поступления в АСУ ГФ, ее защиту, резервное копирование, восстановление.

10.5. Осуществляет техническое сопровождение и консультационную поддержку участников информационного взаимодействия по вопросам использования АСУ ГФ.

12.1. Принимает правовые акты, регламентирующие использование АСУ ГФ, в целях обеспечения бюджетного процесса в городе Москве.

12.2. Осуществляет учет и регистрацию в АСУ ГФ участников информационного взаимодействия.

12.3. Осуществляет методическую поддержку участников информационного взаимодействия АСУ ГФ.

12.4. Обеспечивает составление и актуализацию справочников и классификаторов АСУ ГФ.

13. Поставщик информации АСУ ГФ:

13.1. Осуществляет формирование и ведение информационной составляющей АСУ ГФ в части, относящейся к его компетенции, в соответствии с Регламентом функционирования АСУ ГФ.

13.2. Обеспечивает достоверность и полноту предоставляемой информации.

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

13.4. Обеспечивает обновление данных с момента получения доступа к АСУ ГФ.

14. Пользователь АСУ ГФ:

14.1. Обеспечивает соблюдение требований законодательства о защите информации ограниченного доступа и обеспечении информационной безопасности в отношении сведений, передаваемых с использованием АСУ ГФ.

14.2. Обеспечивает сохранность учетных данных, предоставляемых оператором для использования функциональных возможностей АСУ ГФ, неразглашение указанных данных и недопущение использования функциональных возможностей АСУ ГФ третьими лицами без согласования с оператором.

15. Состав данных, предоставляемых в АСУ ГФ, включает в том числе следующие сведения: по составлению проекта бюджета на очередной финансовый год и плановый период, по перечню распорядителей и получателей бюджетных средств и государственных учреждений города Москвы, по формированию реестра расходных обязательств города Москвы, по планированию бюджетных ассигнований, по государственным программам города Москвы.

Состав указанных данных детализируется в правовых актах, принимаемых в соответствии с пунктами 10.1 и 12.1 настоящего Положения.

16. Сведения, составляющие государственную тайну, не подлежат обработке в АСУ ГФ.

Автоматизированная система управления городскими финансами. дипломная (вкр). информационное обеспечение, программирование. 2021-02-18

Оглавление

Введение

Глава 1. Существующие методические
основы описания бизнес-архитектуры

.1 Описание и анализ подходов к
описанию бизнес-архитектуры

.2 Описание и анализ стандартов
составления технико-экономического обоснования

.3 Описание и анализ моделей оценки
стоимости разработки информационной системы

.4 Описание системы показателей
оценки эффективности разработки информационной системы

Глава 2.Описание бизнес-архитектуры

.1 Краткое описание объекта
автоматизации

.2 Основание для разработки
информационной системы

.3 Назначение и цели разработки
информационной системы

.3.1 Назначение информационной
системы

.3.2 Цели и задачи разработки
информационной системы

.4 Описание функциональных
возможностей

.5 Технологический план

.6 Организационный план

.7 Производственный план

.8 Моделирование процесса разработки
информационной системы

.9 Расчет оценки стоимости
разработки информационной системы

.10 Расчет экономических показателей

.10.1 Расчет ставки дисконтирования

.10.2 Расчет экономических
показателей эффективности

Заключение

Библиографический список

Приложения

Введение

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

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

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

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

Для достижения цели исследования необходимо
решить следующие задачи:

1. Проанализировать подходы к описанию
бизнес-архитектуры.

2.      Сравнить стандарты разработки
технико-экономических обоснований.

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

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

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

Глава 1.    Существующие
методические основы описания бизнес-архитектуры

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

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

1.1    Описание и анализ подходов к
описанию бизнес-архитектуры

бизнес архитектура моделирование
информационный

Термин «архитектура» используется в сфере ИТ
достаточно часто. В большинстве случаев, его применяют к описанию предприятия,
информационной системы или автоматизируемым бизнес-процессам. Впервые данное
понятие было введено Дж. Захманом в 1987 г. в статье «Структура архитектуры
информационных систем» [1]. Опубликованная Дж. Захманом работа касалась
непосредственно архитектуры информационной системы в целом, однако именно она
легла в основу дальнейших разработок в части бизнес-архитектуры.

На данный момент, под термином
«бизнес-архитектура» подразумевают организационную структуру и бизнес-модель
автоматизируемого предприятия, документы, используемые в процессе разработки и
реализации программных продуктов. В действительности, в соответствии со
стандартом ANSI/IEEE 1471-2000 под архитектурой предприятия следует понимать
«фундаментальную организацию системы, реализованную в ее компонентах, связях
этих компонентов друг с другом и внешней средой и принципах, определяющих
структуру и развитие системы».

В соответствии с методологией The
Open Group
Architecture
Framework,
бизнес-архитектура предусматривает формализацию архитектуры деятельности
объекта автоматизации в соответствии с ранее утвержденным видением.

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

В работе Е. Всяких, Е.
Сидоренко,
А. Зуевой, Б. Носкова, А. Киселёва «Практика и проблематика моделирования
бизнес-процессов» авторы рассмотрели следующие подходы к описанию
бизнес-архитектуры: «сверху вниз», «снизу вверх» и гибридный, который частично
включает в себя предыдущие два [3].

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

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

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

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

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

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

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

В данной работе будет использоваться подход
«сверху вниз», так как подход «снизу вверх» в основном используется на
проектах, где разработка осуществляется в условиях высокого уровня
неопределенности.

1.2    Описание и анализ стандартов
составления технико-экономического обоснования

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

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

ГОСТ 24.202-80 – это специально сформированный
перечень требований, утвержденных государством, согласно которым
разрабатывается технико-экономическое обоснование для проектов, в рамках
которых предполагается реализовывать автоматизированные системы управления
(далее АСУ) всех видов. Описываемый стандарт универсален для систем на всех
уровнях управления (помимо общегосударственного).

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

.   Технико-экономическое обоснование разработки
АСУ (далее ТЭО АСУ) предназначено для обоснования необходимости и
технико-экономической целесообразности создания или развития новой
информационной системы.

2.      ТЭО АСУ создается как независимый
документ, составляемый при создании АСУ на действующих или реконструируемых
(реорганизуемых) объектах автоматизации или как раздел в сопутствующих
разработке документах.

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

.        Для вновь проектируемых объектов
управления, исходные данные, необходимые для написания разделов и подразделов
документа ТЭО АСУ, определяют на основе анализа аналогов.

Основным преимуществом данного стандарта
является то, что несмотря на сравнительно краткое содержание, конечный документ
обладает высокой степенью ёмкости предоставляемого материала, помимо этого
стандарт допускает гибкость содержания конечного документа.

В соответствии со стандартом, обязательными для
включения в документ, являются следующие разделы:

·  введение;

·        характеристика объекта и
существующей системы управления;

·        цели, критерии и ограничения
создания;

·        функции и задачи создаваемой
системы;

·        ожидаемые технико-экономические
результаты создания;

·        выводы и предложения.

Второй стандарт был разработан c
помощью United Nations Industrial
Development Organization (далее
UNIDO). Предложенный
UNIDO подход к
подготовке ТЭО, подразумевает под собой тот факт, что целью составления
документа является необходимость в принятии решений об инвестировании и
способах финансирования создания новых продуктов/услуг.

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

Предполагается, что в соответствии со
стандартом, разработанным UNIDO, ТЭО должно отражать описание следующих
положений:

.   Условия реализации проекта (описание
автоматизируемых в плановом периоде бизнес-процессов AS-IS),
уже проведенные ранее исследования в экономической и технической сферах
разработки.

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

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

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

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

.        Финансовая и экономическая оценка
эффективности – общие допустимые инвестиционные издержки с учетом выделяемого
финансирования. Расчет показателей экономической эффективности от реализации
проекта. Допустимо описание бизнес-процессов с помощью подхода TO-BE.

Основным преимуществом описанного стандарта
является тот факт, что в результате проведенного анализа складывается
полноценное представление о специфике и особенностях осуществляемого проекта.
Однако, несмотря на это, стандарт не учитывает характер конкретно заданной
предметной области. В связи с этим, можно сделать вывод о том, что наиболее
подходящим стандартом, который следует использовать в процессе составления ТЭО
для автоматизированной системы управления городскими финансами, является – ГОСТ
24.202-80.

Тем не менее, учитывая предоставляемую
государственным стандартом 24.202-80 возможность дополнения основных положений,
при формировании, в ТЭО будут включены такие разделы как производственный план,
технологический план, организационный план, регламентированные стандартом UNIDO.

1.3     Описание и анализ моделей
оценки стоимости разработки информационной системы

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

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

.   COCOMO 81 (Constructive Cost Model) – это
эмпирическая модель оценки стоимости разработки, предложенная в 1981 году.
COCOMO 81 была создана с опорой на исследование 63 программных проектов
размерностью от 2 000 до 100 000 строк кода и написанных на языках
программирования, начиная с ассемблера [4].

Данные по описанным проектам были исследованы
для того чтобы обнаружить множество закономерностей и формул наиболее
подходящих для проведения наблюдений с использованием модели. Таким образом, в
рамках COCOMO 81, трудоемкость разработки системы – основа оценки ее стоимости,
которая выражается в человеко-месяцах – PM
(Person Months), напрямую зависит от ее размера, а также условий реализации
соответствующего проекта – EM
(Effort Multipliers) и рассчитывается следующим путем:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (1)

где

“a”
и “b” – константы,
соответствующие определенным значениям в рамках модели.

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

.   В 1997 году создана усовершенствованная
модель оценки стоимости разработки информационной системы – COCOMO II.
Согласно обновленной модели, расчет ведется по формуле:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (2)

Где 

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (3)

где

B – коэффициент
зависимости трудозатрат от степени масштабируемости проекта, полученный путем
обработки информации по большому количеству проектов за длительный промежуток
времени.

SF – факторы,
отражающих особенности проекта и коллектива разработчиков.

Всего в модели COCOMO II
используется 31 параметр для прогнозирования затрат различного характера на
разработку информационной системы. Такой большой объем анализируемого материала
линейно зависит от непосредственной оценки стоимости выявляемой с помощью
моделирования, то есть прогноз в большинстве случаев имеет высокий уровень
достоверности, точности.

3. SEER (System Evaluation and
Estimation of Resources) – запатентованная
модель,
которая
принадлежит
корпорации
“Galorath Associates”. Принципы расчётов SEER
основаны на ранних исследовательских работах доктора наук Рэнделла Йенсена.
Основное уравнение, используемое в концепции модели:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (4)

где

S – количество
эффективных (не закомментированных), исполняемых строк кода, обеспечивающих
функционирование информационной системы.

Ct –
константа, используемая для оценки технологии применяемой разработчиком.

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

K – общая стоимость
обеспечения жизненного цикла информационной системы в человеко-лет.

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

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

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

.   Модель оценки стоимости разработки SLIM
(Software
Life-Cycle
Model). Применяется в
основном для крупных проектов, где информационные системы по размерности
составляют 70 000 строк кода. Основана на распределении Рэлея – это
распределение вероятностей случайной величины “x” с плотностью [5].модель
использует два уравнения: уравнение измерения трудоемкости разработки
информационной системы и уравнение вычисления уровня производительности
информационной системы. Распределение Рэлея применяется в рамках модели с целью
оценки точности составления производственного графика разработки и учета
вероятности наступления тех или иных рисков. Таким образом, два ключевых
атрибута, предлагаемых к использованию в модели SLIM
– коэффициент производительности (PI)
и индекс трудоемкости (MBI).

Основная формула, применяемая при расчётах согласно
модели SLIM (включает
два вышеописанных уравнения):

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (5)

где

dy/dt
– оценка трудоемкости приведенная к единице времени.- общая стоимость
обеспечения жизненного цикла системы.

a – параметр
масштаба информационной системы.

t – прошедшее с
момента начала разработки время.

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

Как показал сравнительный анализ,
самым лучшим вариантом для оценки стоимости разработки информационной системы
«Автоматизированная система управления городскими финансами» является модель –
COCOMO II. Это связано с тем, что аналогичные модели в меньшем объеме учитывают
основные факторы, участвующие в оценке стоимости. В данном случае достоверность
оценки прямо пропорциональна количеству факторов, которые учитываются в
концепции модели.

Таблица 1. Сравнение моделей оценки
стоимости разработки информационных систем

Группа

Фактор

SLIM

SEER

COCOMO II

COCOMO

Атрибуты размера

Функциональные точки

Да

Да

Да

Да

Объектно-ориентированные метрики

Да

Да

Да

Нет

Атрибуты системы

Тип системы

Да

Да

Нет

Нет

Сложность

Да

Да

Да

Да

Требуемая надежность

Нет

Нет

Да

Нет

Атрибуты персонала

Возможности персонала

Да

Да

Да

Да

Занятость персонала

Нет

Нет

Да

Нет

Компетенции персонала

Да

Да

Да

Да

Атрибуты проекта

Инструменты и техники

Да

Да

Да

Да

Уязвимости/риски

Да

Да

Да

Нет

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

Да

Да

Да

Да

Информационная безопасность

Нет

Нет

Да

Нет

Активность

Подготовка

Да

Да

Да

Да

Разработка

Да

Да

Да

Да

Завершение

Да

Да

Да

Да

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

Да

Да

Да

Да

1.4   

1.4 Описание системы показателей
оценки эффективности разработки информационной системы

Экономическая эффективность в самом общем смысле
есть сравнение результатов хозяйственной деятельности с затраченными на эту
деятельность ресурсами: трудовыми, материальными, природными [6].

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

Для оценки эффективности деятельности
предприятия выделяют две группы показателей:

1.   Показатели прибыльности

Ключевыми показателями прибыли являются:

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

·        себестоимость – прямые затраты,
связанные непосредственно с разработкой информационной системы;

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

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

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

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

2.   Показатели рентабельности

Обычно к ключевым показателям рентабельности
относят:

·    маржу – долю валовой прибыли в выручке (процент
стоимости, который нужно добавить, чтобы получить цену);

·        наценку – долю валовой прибыли в
себестоимости;

·        рентабельность продаж – долю чистой
прибыли в выручке;

·        рентабельность активов – долю чистой
прибыли в активах;

·        рентабельность собственного капитала
– долю чистой прибыли в собственном капитале.

Кроме разделения на показатели прибыльности и
показатели рентабельности показатели эффективности еще принято делить на:

.     Относительные – показывают соотношение
полученного эффекта с затратами на его осуществление и являются своего рода
платой за достижение данного результата.

2.      Абсолютные – отражают уровень развития
предприятия, достигнутый за определенный промежуток времени.

Основные принципы оценки эффективности
деятельности предприятия базируются на основе учета влияния инфляции и учета (в
количественной форме) влияния неопределенностей и рисков. Чаще всего для оценки
эффективности применяют абсолютные показатели:

1)   валовая прибыль – разница между валовым
доходом и издержками, связанными с получением дохода;

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (6)

2)   операционная прибыль (прибыль до уплаты
процентов за кредит и налога на прибыль) – вычисляется как разница валовой
прибыли и амортизации;

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (7)

3)   чистый операционный доход (чистая прибыль)
– разница между операционной прибылью, налогами и процентами по кредитам;

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (8)

4)   чистый операционный денежный поток (в
основном используется как база для расчета других показателей) – вычисляется
как сумма чистой прибыли и амортизации;

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (9)

5)   чистая приведенная стоимость – разница
между суммой дисконтированных денежных потоков и первоначальными инвестициями.

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (10)

где

I0 – начальные
инвестиции, i – месячная ставка
дисконтирования [7].

Расчёт NPV
показывает оценку эффекта от инвестиции, приведённую к настоящему моменту
времени с учётом разной временной стоимости денег. Если NPV
больше 0, то инвестиция экономически эффективна, а если NPV
меньше 0, то инвестиция экономически невыгодна. Именно с помощью NPV можно
вычислить срок окупаемости деятельности предприятия.

Для вычисления всех названных показателей
сначала вычисляют ставку дисконтирования. Ставка дисконтирования отражает
стоимость привлеченного капитала с учетом временного фактора и рисков.

Существует несколько способов расчета ставки
дисконтирования. Выделяют кумулятивный и укрупненный метод оценки ставки
дисконтирования.

I.       Кумулятивныйметод ставки дисконтирования представляет собой расчет по следующей
формуле:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (11)

гдеmin
– минимальная реальная ставка дисконтирования (как правило, за минимальную
реальную ставку дисконтирования принимают 30-летние государственные облигации
США).- уровень инфляции.- премия за риск.

Премия за риск также является вычисляемым
показателем, и представляет собой следующую сумму:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (12)

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

II.      Укрупненный метод
предполагает расчет средневзвешенной стоимости капитала (WACC),
которая учитывает стоимость собственного капитала и стоимость заемных средств:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (13)

где

Re – ставка
доходности собственного капитала.

E – рыночная
стоимость собственного капитала.

D – рыночная
стоимость заемного капитала.

Читайте также:  Ключи эцп гост

V – сумма стоимости
займов и собственного капитала.d
– ставка доходности заемного капитала.

t – ставка налога на
прибыль.

Ставка доходности собственного капитала (Re)
вычисляется по формуле:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (14)

где

Rf –
безрисковая ставка дохода.

β – коэффициент,
определяющий изменение цены на акции компании по сравнению с изменением цен на
акции по всем компаниям данного сегмента рынка.

Rm –
среднерыночная ставка доходности на фондовом рынке (Rm
– Rf – премия за
рыночный риск).

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

)        реальная годовая ставка дисконтирования:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт  (15)

2)      реальная месячная ставка
дисконтирования:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (16)

Глава 2.    Описание
бизнес-архитектуры

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

2.1     Краткое описание объекта
автоматизации

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

Свою деятельность в рамках реализации бюджетного
процесса Департамент финансов осуществляет в соответствии с постановлением от
22 февраля 2021 г. № 43-ПП «Об утверждении Положения о Департаменте финансов».

Порядок организационного, документационного,
информационного обеспечения деятельности Департамента финансов определяет
«Регламент Департамента финансов» (Приложение к Приказу Департамента финансов
от 23 апреля 2009 г. № 58, в редакции приказов Департамента финансов от 28
сентября 2009 г. № 108 и от 13 июля 2021 г. № 133).

Распределение ответственности между структурными
подразделениями Департамента Финансов за предоставление показателей по разделам
и подразделам классификации расходов бюджета, по главным распорядителям
бюджетных средств, по государственным программам, по источникам финансирования
дефицита бюджета определяет Приказ Департамента финансов № 36 «Об утверждении
перечней ответственных структурных подразделений Департамента финансов».

Этапы составления бюджета регламентированы
постановлением от 14 февраля 2021 г. № 42-ПП «Об утверждении Положения о
составлении проектов бюджета города и бюджета городского фонда обязательного
медицинского страхования на очередной финансовый год и плановый период».

2.2   Основание для разработки информационной
системы

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

1.   Приказ Министерства финансов Российской
Федерации от 08 июня 2021 г. № 90н «О внесении изменений в Указания о порядке
применения бюджетной классификации Российской Федерации, утвержденные приказом
Министерства финансов Российской Федерации от 1 июля 2021 г. № 65н».

2.      Приказ Министерства финансов Российской
Федерации от 22 сентября 2021 г. № 145н «Об утверждении Методических
рекомендаций по представлению бюджетов субъектов Российской Федерации и местных
бюджетов и отчетов об их исполнении в доступной для граждан форме».

.        Распоряжение Правительства Российской
Федерации от 30 декабря 2021 г. № 2593-р «Об утверждении Программы повышения
эффективности управления общественными (государственными и муниципальными)
финансами на период до 2021 года» о разработке информационных подсистем
управления государственными и муниципальными финансами публично-правовых
образований и организаций сектора государственного управления.

.        Постановление Правительства от 9
августа 2021 г. № 349-ПП «Об утверждении государственной программы
«Информационный город» на 2021-2021 годы» (в ред. Постановления Правительства
от 01.12.2021 №814-ПП).

4.1.   Подпрограмма 12.02.000.000.00. Повышение
эффективности реализации функций органами исполнительной власти за счет
внедрения информационно-коммуникационных технологий.

.1.1.  Мероприятие 12.02.002.000.00. Повышение
эффективности системы управления финансовой и экономической деятельностью за
счет внедрения информационно-коммуникационных технологий.

2.3 Назначение и цели разработки
информационной системы

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

2.3.1 Назначение информационной
системы

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

.   информационно-аналитической поддержке
процесса формирования доходной и расходной части бюджета;

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

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

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

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

Пользователями системы в плановом периоде
являются органы исполнительной власти, в т.ч.:

.   финансовый орган – Департамент финансов;

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

.        главные распорядители бюджетных средств
(далее ГРБС), распорядители бюджетных средств, главные администраторы доходов
бюджета.

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

2.3.2 Цели и задачи разработки
информационной системы

Основными целями разработки системы являются:

·  повышение эффективности процесса подготовки
расходной и доходной части проекта бюджета;

·        повышение открытости и прозрачности
бюджета;

·        повышение качества контроля
бюджетного процесса;

·        повышение эффективности формирования
и контроля исполнения планов финансово-хозяйственной деятельности учреждений;

Основными индикаторами достижения поставленных
целей являются:

.   перевод электронных документов, участвующих
в формировании доходной и расходной частях бюджета, на электронный документооборот;

2.      ведение в электронной форме планов
финансово-хозяйственной деятельности, включающих в себя дополнительную
детализацию расходов и доходов бюджета;

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

Основными решаемыми задачами в процессе
разработки системы являются:

·  внедрение юридически значимого электронного
документооборота в части формирования органами государственной власти прогнозов
поступления доходов и источников финансирования дефицита бюджета, кассового
плана доходов и источников финансирования дефицита бюджета;

·        создание подсистем информационной
системы «Автоматизированная система управления городскими финансами»;

·        обеспечение возможности применения
кодов бюджетной классификации в соответствии с принципами, установленными
Федеральным законом от 22.10.2021 № 311-ФЗ.

2.4    Описание функциональных
возможностей

Функциональные возможности, требуемые к реализации
со стороны Исполнителя по разработке подсистемы «Планирование расходной части
бюджета»:

•  формирование бюджетных ограничений;

•        вариантное планирование расходной части
бюджета;

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

1. Модуль формирования бюджетных
ограничений.

Модуль должен обеспечивать реализацию следующих
возможностей:

–       определение бюджетных ограничений
для проекта бюджета;

–       определение бюджетных ограничений в
автоматизированном режиме:

·        ведение дополнительных
классификаторов. (Исполнитель должен обеспечить первоначальное наполнение
дополнительных классификаторов на основании информации, предоставленной
Заказчиком);

·        определение расчетных показателей
бюджета (бюджетных ограничений) – инструментарий системы должен обеспечить
следующие возможности:

ü    индексация расходов в соответствии с
настроенными правилами, ведение и учет исключений из правил индексирования;

ü  ввод корректировочных поправок –
ввод экспертных корректировок для увеличения / сокращения объемов бюджетных
ассигнований;

–       ручной ввод бюджетных ограничений;

–       подготовка отчетности и
аналитических материалов на основании информации модуля.

2. Модуль вариантного планирования
расходной части бюджета.

Модуль должен обеспечивать реализацию следующих
возможностей:

–       подготовка неограниченного числа
версий проекта бюджета – при этом новая версия проекта бюджета должна
создаваться только после утверждения предыдущей (последовательно);

–       ввод данных по проекту бюджета с
учетом бюджетных ограничений;

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

–       отправка ГРБС данных по проекту
бюджета, изменениям в проект бюджета на согласование в адрес Департамента
финансов;

–       согласование либо возврат на
доработку сотрудником Департамента финансов данных по проекту бюджета,
изменениям в проект бюджета в адрес ГРБС;

–       утверждение версии проекта бюджета;

–       подготовка приложений к закону о
бюджете по расходам.

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

Функциональная возможность должна обеспечивать
реализацию:

–       Методического обеспечения в части
планирования межбюджетных трансфертов;

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

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

–       обследование правового регулирования
и практики предоставления межбюджетных трансфертов за 2021-2021 годы, выявить
сильные и слабые стороны организации предоставления межбюджетных трансфертов;

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

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

·        распределения дотаций на
выравнивание бюджетной обеспеченности муниципальных образований;

·        правового регулирования
предоставления субвенций для осуществления переданных органам местного
самоуправления отдельных государственных полномочий;

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

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

·        о внесении изменений и дополнений в
Закон от 10.09.2008 № 39 «О бюджетном устройстве и бюджетном процессе»;

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

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

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

–       отображение перечня межбюджетных
трансфертов;

–       формирование расчета межбюджетных
трансфертов, в т.ч.:

·        ручной ввод исходных данных (данные,
используемые для расчетов) в разрезе муниципальных образований;

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

–       формирование приложений к закону о
бюджете в части межбюджетных трансфертов в формате Excel.

Внедрение программного принципа на
местном уровне.

Назначением модуля должно являться обеспечение
следующих возможностей:

–       методическое обеспечение в части
внедрения программного принципа на местном уровне;

–       прототип программного обеспечения по
представлению местных бюджетов в программном виде.

Методическое обеспечения в части внедрения
программного принципа на местном уровне должно обеспечивать:

–       разработку подходов к организации
комплексного внедрения программного принципа на местном уровне;

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

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

·        типовые муниципальные правовые акты,
необходимые для перехода на программные принципы на муниципальном уровне;

·        типовые муниципальные программы для
одного пилотного муниципального образования в пилотных сферах;

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

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

–       формирование программ органа
местного самоуправления (далее – ОМСУ), в т.ч.:

·        определение состава программ
(добавление, удаление программы из перечня);

·        определение структуры программы;

·        ввод информации по разделам
программы (паспорт, показатели, финансирование и др.);

–       ввод сведений о реализации программ
ОМСУ (показатели, финансирование);

–       формирование отчетности в формате
Excel:

·        регламентного отчета по программе;

·        сводного отчета по всем программам
ОМСУ;

·        отчета об исполнении программы.

Мониторинг исполнения местных
бюджетов и оценка качества финансового менеджмента:

Назначением модуля должно являться обеспечение
следующих возможностей:

–       Разработка методического обеспечения
в части внедрения на муниципальном уровне оценки качества финансового менеджмента
на муниципальном уровне;

–       Прототип программного обеспечения по
проведению оценки качества финансового менеджмента на муниципальном уровне;

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

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

–       разработку подходов к внедрению на
муниципальном уровне оценки качества финансового менеджмента;

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

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

Функциональные возможности, требуемые к
реализации со стороны Исполнителя по разработке подсистемы «Планирование и
анализ доходной части бюджета»:

•  вариантное планирование расходной доходной
бюджета.

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

Подсистема «Автоматизированное рабочее место
руководителя Департамента финансов» предназначена для визуализации информации о
бюджете, а также предоставления руководителю Департамента финансов функций
мобильного офиса.

В рамках выполнения работ по разработке
веб-приложения должны быть разработаны механизмы:

–    формирования и вывода на печать графика
мероприятий;

–       выгрузки экранных форм в файлы
форматов Adobe PDF и MS
Excel;

–       разграничения прав пользователей,
позволяющие выдавать разрешения на редактирование определённых разделов;

–       журналирования действий
пользователей.

Исполнителем также должны быть разработаны
инструменты:

–    согласования пакетов документов на внесение
изменений в сводную бюджетную роспись с использованием электронной подписи;

–       ввода и отображения еженедельной
отчетной информации по государственному долгу;

–       ввода и отображения информации по
исполнению доходной части бюджета;

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

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

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

·  реализация механизма подписания электронных
документов юридически значимой электронной подписью;

·        реализация механизма проверки
открытой части ключа электронной подписи (далее ЭП);

·        реализация механизма проверки
электронной подписи;

·        реализация механизма включения
штампа времени в ЭП;

Подсистема «Аналитической обработки данных»
должна быть предназначена для консолидации информации о бюджетном процессе и
социально-экономическом развитии.

В рамках выполнения работ по развитию подсистемы
должны быть разработаны:

·  механизмы ведения реестра открытых данных
Департамента финансов и передача их на «Портал открытых данных Правительства»;

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

2.5    Технологический план

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

Характеристики окружающей среды в местах
установки технических средств должны соответствовать требованиям следующих
документов:

·  ГОСТ Р ИСО 14001-98. Системы управления
окружающей средой. Требования и руководство по применению.

·        СанПиН 2.2.24.548-96. Физические
факторы производственной среды. Гигиенические требования к микроклимату
производственных помещений.

·        СанПиН 2.2.2/2.4.1340-03.
Гигиенические требования к персональным электронно-вычислительным машинам и
организации работы.

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

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

Рабочие места пользователей должны
функционировать под управлением операционных систем MS Windows 2000/XP/Vista/7.
На рабочих местах пользователей должно быть установлено следующее программное
обеспечение:

·  браузер Mozilla
Firefox 18.0, Google Chrome 24.0 (и
выше),
Internet Explorer 9 (и выше);

·        Microsoft Office 2007 (и выше).

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

·  операционная система Microsoft Windows Server
2008 R2;

·        СУБД
Microsoft SQL Server 2008 R2 или
Oracle 11gR2.

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

·  операционная система
Microsoft Windows Server 2008 R2;

·        Microsoft Internet
Information Server 7.0 (и выше)
или
Apache Tomcat 7;

·        Microsoft .Net Framework 4.0.

Расходы на техническую поддержку
рабочей группы могут быть представлены в табличной форме (см. Таблица 2).

Таблица 2. Перечень накладных
расходов на обеспечение технологического процесса

Статьи накладных расходов

1.

Аренда (или амортизация
собственных) зданий/помещений (минимальный норматив 4,5 кв. м. на 1 человека,
умноженный на 2 для учета помещений общего пользования и администрации, при
ставке помещений 40 000 руб./кв. м. в год)

2.

Амортизация оборудования,
технических средств

2.1.

Компьютер – 20 000 руб. при сроке
службы 3 года (2-я амортизационная группа)

2.2.

Стол – 8 000 руб. при сроке службы
7 лет (4-я амортизационная группа)

2.3.

Стул – 2 000 руб. при сроке службы
7 лет (4-я амортизационная группа)

2.4.

Тумба – 2 000 руб. при сроке
службы 7 лет (4-я амортизационная группа)

2.5.

Прочие (доля от шкафов для одежды,
для документов, офисной оргтехники и т.д.) – 10 000 руб. при сроке службы 7
лет (4-я амортизационная группа)

4.

Прочие расходы (принимаются на
уровне 15% от ФОТ) · содержание и ремонт
зданий/помещений, сооружений и оборудования; · содержание
и обслуживание программных и технических средств; · расходы
на связь, средства коммуникации, интернет; · прочие.

4.1.

·

4.2.

·

4.3.

·

4.4.

·

Амортизационные группы определены по
государственному классификатору.

2.6 Организационный план

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

Существует шесть основных типов организационных
структур:

1. линейная;

2.      функциональная;

.        линейно-функциональная;

.        матричная;

.        дивизиональная;

.        множественная.

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

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

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

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

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

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

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

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

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

•        для функционирования системы не должно
требоваться круглосуточного обслуживания системы и присутствия администраторов
у консоли управления.

Согласно техническому заданию,
опубликованному среди прочих документов на web-странице
конкурса (сайт государственных закупок), состав задействованных в разработке
системы сотрудников должен соответствовать перечню, представленному в Таблице 3.

Таблица 3. Квалификационный состав
проектной команды

Наименование должности

Фактическое время участия (рабочих
дней)

Численность исполнителей

1

Руководитель проекта

148

1

2

Проектный менеджер

148

5

3

Администратор проекта

148

6

4

Главный аналитик

148

5

5

Аналитик

140

20

6

Главный архитектор

120

1

7

Главный инженер

140

1

8

Разработчик

110

20

9

Тестер

100

5

10

Технический писатель

75

5

11

Консультант

65

5

12

Инженер-техник

80

5

2.7   Производственный план

Сокращенный вариант
производственного плана реализации разработки и развития информационной системы
«Автоматизированная система управления городскими финансами» может быть
представлена в виде Таблицы 4. Полная версия производственного плана содержится
в Приложении B.

Таблица 4. Первый уровень
декомпозиции производственного плана

Наименование задачи

Сроки

Начало

Окончание

Длительность, рабочих дней

Этап 1. Обследование объекта
автоматизации и уточнение требований к системе

26.05.2021

15.07.2021

35

Этап 2. Техно-рабочий проект
Системы в рамках реализации функций первой части

16.07.2021

13.09.2021

42

Этап 3. Техно-рабочий проект
Системы в рамках реализации функций второй части

14.09.2021

22.11.2021

49

Этап 4. Опытная эксплуатация и
приемка Системы

14.09.2021

22.12.2021

71

Первый этап «Обследование объекта автоматизации
и уточнение требований к системе» содержит подзадачи:

.       Обследование и уточнение требований:

.1.    Уточнение основных требований к
подсистеме «Планирование и анализ доходной части бюджета».

1.2.   Уточнение основных требование к
подсистеме «Планирование расходной части бюджета».

.3.     Уточнение основных требований к
подсистеме «Автоматизированное рабочее место руководителя Департамента
финансов».

.4.     Уточнение основных требований к
подсистеме аналитической обработки данных.

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

2.   Обеспечение информационной безопасности
(далее ИБ):

2.1.  Анализ обрабатываемых документов и
классификация.

2.2.   Анализ угроз и описание потенциальных
угроз и действий нарушителя ИБ.

.3.     Анализ и формирование требований по
обеспечению ИБ.

3.   Документирование:

3.1.  Оформление и согласование отчета об
обследовании.

3.2.   Описание бизнес-сценариев
автоматизируемых процессов.

.3.     Оформление и согласование частного
технического задания.

Длительность первого этапа составляет 35 рабочих
дней. В работе над проектом в рамках данного этапа помимо руководителей
задействованы: главные аналитики, аналитики, технические писатели.

Второй этап «Техно-рабочий проект системы в
рамках реализации функций первой части» более объемный и содержит подзадачи:

1. Системное проектирование.

2.      Внедрение юридически значимого
электронного документооборота:

.        Обеспечение возможности применения
кодов бюджетной классификации в соответствии с принципами, установленными
Федеральным законом от 22.10.2021 № 311-ФЗ.

.        Разработка подсистемы «Планирование и
анализ доходной части бюджета».

.        Разработка подсистемы «Планирование
расходной части бюджета».

.        Разработка подсистемы
«Автоматизированное рабочее место руководителя Департамента финансов».

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

8. Создание модуля формирования предложений по
распределению предельных объемов бюджетных ассигнований.

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

.        Создание подсистемы «Обеспечения
юридической значимости».

.        Интеграционное тестирование и отладка.

.        Документирование:

12.1.     Технический проект:

12.1.1.  Пояснительная записка к техническому
проекту системы.

12.1.2.        Описание архитектуры системы.

12.2.     Рабочая документация:

12.2.1.  Общее описание системы.

12.2.2.        Руководство пользователя системы.

.2.3.  Руководство администратора системы.

.2.4.  Программа и методика предварительных испытаний.

.2.5.  Программа опытной эксплуатации системы.

.2.6.  Акт ввода системы в опытную эксплуатацию
(проект).

12.3.     Ведомость машинных носителей
информации.

13. Пуско-наладочные работы.

14.    Предварительные испытания.

Длительность второго этапа составляет 42 рабочих
дня. В работе над проектом в рамках данного этапа помимо руководителей
задействованы все участники проектной команды: главные аналитики, аналитики,
технические писатели, разработчики, тестеры и др.

Третий этап «Техно-рабочий проект системы в рамках
реализации функций второй части» по объему работ близок похож на второй и
содержит подзадачи:

1.   Системное проектирование

2.      Развитие подсистемы «Планирование
расходной части бюджета».

.        Развитие подсистемы «Планирование и
анализ доходной части бюджета».

.        Развитие подсистемы «Автоматизированное
рабочее место руководителя Департамента финансов».

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

.        Создание подсистемы аналитической
обработки данных.

.        Развитие подсистемы «Обеспечения
юридической значимости».

.        Разработка подсистемы «Сводная
бюджетная роспись».

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

.        Развитие модуля формирования
предложений по распределению предельных объемов бюджетных ассигнований.

.        Интеграционное тестирование и отладка.

.        Документирование:

12.1.     Технический проект:

.1.1.      Пояснительная записка к техническому
проекту системы.

12.1.2.        Описание архитектуры системы.

12.2.     Рабочая документация:

.2.1.      Общее описание системы.

12.2.2.        Руководство пользователя системы.

.2.3.  Руководство администратора системы.

.2.4.  Программа и методика предварительных
испытаний системы.

.2.5.  Программа опытной эксплуатации системы.

.2.6.  Акт ввода системы в опытную эксплуатацию
(проект).

.2.7.  Ведомость машинных носителей информации.

13. Пуско-наладочные работы.

14.    Предварительные испытания.

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

Четвертый этап «Опытная эксплуатация и приемка
системы» является завершающим и содержит подзадачи:

.     Обучение и консультация персонала системы
по новым компонентам:

.1.  Техническое и сервисное сопровождение новых
компонент системы.

1.2.   Проведение оптимизации подсистем.

.3.     Анализ и устранение ошибок, выявленных в
ходе опытной эксплуатации.

2.   Документирование:

.1.  План-программа подготовки персонала.

2.2.   Отчет о подготовке персонала.

.3.     Акт о проведении подготовки персонала.

.4.     Журнал проведения опытной эксплуатации.

.5.     Акт о завершении опытной эксплуатации.

.6.     Программа и методика комплексных приемочных
испытаний.

.7.     Акт о готовности системы к промышленной
эксплуатации.

3.   Комплексные приемочные испытания.

4.      Проектный офис:

4.1.       Общее управление проектом.

4.2.   Координация проектной команды.

.3.     Администрирование проекта.

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

Общие затраты на реализацию разработки системы
составляют 148 рабочих дней.

2.8 Моделирование процесса
разработки информационной системы

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

Таблица 5. Перечень диаграмм,
описывающих процесс разработки

Наименование диаграммы

Описание

Приложение

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

1 Уровень: иллюстрирует всю
деятельность Исполнителя на самом верхнем уровне.

Приложение С

2 Уровень: показывает процесс
разработки и связанные с ним напрямую бизнес-процессы такие как контроль
качества или обучение персонала функционального Заказчика.

Приложение D

Событийная цепочка процесса

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

Приложение E

Диаграмма окружения процесса

Показывает окружение
бизнес-процесса: участвующие в процессе нормативные документы, участвующие
подразделения

Приложение F

2.9 Расчет оценки стоимости
разработки информационной системы

В качестве основы расчета оценки стоимости
разработки информационной системы была выбрана модель – COCOMO II.
Согласно описываемой модели расчёты должны осуществляться следующим образом:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (17)

где

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

Size – сумма
строк кода, представленная в тыс. строк (KSLOC).- множители трудоемкости
разработки.

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт  (18)

где

B – коэффициент
зависимости трудозатрат от степени масштабируемости проекта, полученный путем
обработки информации по большому количеству проектов за длительный промежуток
времени.

SF – факторы,
отражающих особенности проекта и коллектива разработчиков.

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

Входными параметрами для расчета трудоемкости
являются:

·  количество строк кода, подсчитанное исходя из
оценки User Function Types (логических групп данных, которые используются и
поддерживаются системой, и функциональности совершаемых транзакций);

Читайте также:  Как работать с электронной подписью без флешки? - Изготовим ЭЦП за 30 минут

·        интегральная оценка масштабируемости
проекта;

·        интегральные множители трудоемкости.

Вычисление Size(количество
строк кода, выраженное в тысячах строк):

Для вычисления количество строк кода по модели
COCOMO-II необходимо произвести оценку User
Function
Types (логических групп
данных и функциональности совершаемых транзакций в системе), после чего,
согласно таблице весов (Model
Definition
Manual), определить
ненормированное количество функциональных точек (Unadjusted
Function
Point, UFP). Далее для
предполагаемого языка программирования следует определить коэффициент отношения
строчек кода к UFP (Model
Definition
Manual) и на основании
данного коэффициента и числа UFP подсчитать Size.

Общая функциональность определяется путем:

1.   Анализа логических групп данных, которые
используются и поддерживаются системой (точки типа ILF и EIF):

·        ILF
– Internal
Logical File
– внутренний логический файл (логически связанная группа данных, определяемая
пользователем и находящаяся внутри границ проекта).

·        EIF
– External
Interface
Files – внешний
интерфейсный файл (логически связанная группа данных, обеспечивающая
программное обеспечение информацией, но лежащая за его пределами и
поддерживаемая другим программным обеспечением).

2.   Анализа функциональности совершаемых
транзакций (точки типа EInp, EO и EInq):

·        EInp
– External
Input – внешний вход
(процесс ввода данных и управляющей информации).

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

·        EInq – External Inquiry – внешний
запрос (диалоговый ввод, который приводит к немедленному ответу ПС в форме
диалогового вывода).

Итоговое количество функциональных
точек в системе представлено в Таблица6. Оно составляет 4 027,5 ед.

Таблица 6. Количество User Function
Types в системе

Тип

Всего

Из них по уровню сложности

Весовые коэффициенты уровней
сложности по модели COCOMO-II

Низкий

Средний

Высокий

Низкий

Средний

Высокий

ILF

142,0

58,0

17,0

67,0

3,0

4,0

6,0

644,0

EIF

79,0

25,0

12,0

42,0

4,0

5,0

7,0

454,0

EInp

165,0

66,0

47,0

52,0

7,0

10,0

15,0

1 712,0

EO

107,9

43,9

22,0

42,0

5,0

7,0

10,0

793,5

EInq

97,0

38,0

22,0

37,0

3,0

4,0

6,0

424,0

Всего

590,9

4 027,5

На основе данных, полученных из инструкции Model
Definition Manual к модели COCOMO-II, коэффициент UFP для языка Java (Eclipse),
на котором в плановом периоде будет реализована большая часть подсистем
составляет 53.

Таким образом, число строк кода составляет 4
027,5 x 53 = 213 457,5, а переменная Size,
(количество строк кода, выраженная в тысячах строк) – 213, 46.

Вычисление Е – интегральной оценки
масштабируемости проекта:

Методика COCOMO II позволяет оценить влияние
масштабов проекта на эффективность процесса разработки программного продукта.
Данная зависимость в формуле расчета трудоемкости оценивается коэффициентом
масштаба E.

Е – интегральная оценка масштабируемости проекта
рассчитывается на основании оценки факторов масштаба и имеет вид:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт  (19)

где

B – коэффициент
зависимости трудозатрат от степени масштабируемости проекта, полученный путем
обработки информации по большому количеству проектов за длительный промежуток
времени.

SF – факторы,
отражающих особенности проекта и коллектива разработчиков.

В Таблица 7 представлена оценка
состояния масштабирующих факторов, проведенная на основе значений, полученных с
помощью использования инструкции Model Definition Manual созданной специально
для COCOMO-II.

Таблица 7. Перечень параметров
масштабируемости системы

IND

Название

Состояние

Знач.

PREC

Прецедентность

Продукт и платформа в целом
изучены

1,24

FLEX

Гибкость процесса разработки

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

3,04

RESL

Разрешение рисков

Часть рисков разрешена

4,24

TEAM

Сработанность команды

Коммуникативные проблемы
существуют

3,29

PMAT

Зрелость процессов

Уровень 3 (выше среднего)

3,12

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

,91 0,01 x
(1,24 3,04 4,24 3,29 3,12) = 1,059 ед.

Вычисление EMi – множителей
трудоемкости:

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

В Таблице 8 приведена оценка
состояния множителей трудоемкости, значений EMi, полученных на основе данных
технического задания и инструкции Model Definition Manual к модели COCOMO-II.

Таблица 8. Оценка множителей
трудоемкости

IND

Название

Состояние

Знач.

RELY

Требуемая надежность

Номинальный. Имеются
незначительные неудобства

1,00

DATA

Размер тестовых данных

D/P >= 1000

1,28

CPLX

Сложность продукта

Высокая

1,17

RUSE

Возможность использования продукта
в дальнейших разработках

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

1,15

DOCU

Полнота документации

Соответствует требованиям к
документации

1,00

TIME

Ограничения по доступности
программной среды

Ограничение 50% и менее от общего
доступного времени 1,00

1,00

STOR

Ограничение памяти

Занято до 50% доступного ресурса

1,00

PVOL

Платформа разработки

Минимальная частота изменения – 2
месяца; Максимальная частота изменения – 1 неделя.

1,15

ACAP

Квалификация аналитиков

75%

0,85

PCAP

Квалификация разработчиков

55%

1

PCON

Проектная команда

12% в год

1,00

APEX

Опыт разработки приложений

6 лет и более

0,81

PLEX

Знание платформы

6 лет и более

0,85

LTEX

Знание языка и среды разработки

6 лет и более

0,84

TOOL

Среда разработки

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

1,0

SITE

Распределенная разработка (SITE)

Разработка распределена в разных
городах и компаниях. Использование телефонов, факсов

1,09

SCED

Корректировка графика (SCED)

75%

1,43

Итого ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт 1,518 ед.

Итоговый расчет трудоемкости
разработки системы:

Трудоемкость проекта в человеко-месяцах в
соответствии с моделью COCOMO II равна: PM = 2, 94 x 213,461,0593 x 1,518 = 1
309,03
ед.

Для определения стоимости разработки
системы требуется вычислить стоимость единицы трудоемкости (см. Таблица 9)

Таблица 9. Перечень расходов,
составляющих стоимость единицы трудоемкости

Статья

Сумма, руб. на 1 специалиста в
месяц

% от СС

% от стоимости 1 человеко-месяца

1

Зарплата основных специалистов
(ФОТ) (Мосгорстат, январь-май 2021)

58 052,90

49%

43%

2

Страховые взносы в ПФ, ФМС, ФСС
(30,2%)

17 415,87

15%

13%

3

Накладные расходы (73% от ФОТ)

42 432,83

36%

31%

4

Итого расходы (себестоимость (СС))

117 901,60

100%

87%

5

Прибыль (15% на итого расходы)

17 685,24

15%

13%

6

Стоимость 1 человеко-месяца, без
НДС

135 586,84

115%

100%

7

Стоимость 1 человеко-дня, без НДС

6 587,21

Стоимость 1 человеко-дня вычисляется как
стоимость 1 человеко-месяца умноженная на 12 (количество месяцев в году) и
деленная на 247 (количество рабочих дней в 2021 году).

Среднемесячная заработная плата работников за
январь-май 2021 года по полному кругу организаций, на основе данных Мосгорстата
по виду деятельности «Разработка программного обеспечения и консультирование в
этой области» составляет в среднем 58 052,90 руб.

Расчет суммарного размера тарифов
страховых взносов в 2021 году, представленный в табличном формате – Таблица 10.

Таблица 10. Страховые взносы в ПФ,
ФМС, ФСС

Наименования тарифов страховых
взносов

Ставка на 2021 год, %

1

Тариф страховых взносов,
уплачиваемых в Пенсионный фонд РФ

22,0%

2

Тариф страховых взносов,
уплачиваемые в Фонд социального страхования РФ

2,9%

3

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

3,1%

4

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

2,0%

5

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

0,2%

6

ИТОГО суммарный размер тарифов
страховых взносов в 2021 г.

30,2%

Расчет размера накладных расходов в
% от фонда оплаты труда, представленный в табличном формате – Таблица 11.

Таблица 11. Полный перечень
накладных расходов на реализацию проекта

Статьи накладных расходов / % от
фонда оплаты труда

Сумма

1.

Административно-управленческие
расходы (норма управляемости = 1 непосредственный руководитель на 7
специалистов с ЗП в 1,5 раз выше 1 высший руководитель, с учетом страховых
взносов)

34,9%

2.

Аренда (или амортизация
собственных) зданий/помещений (минимальный норматив 4,5 кв. м. на 1 человека,
умноженный на 2 для учета помещений общего пользования и администрации, при
ставке 40 000 руб./кв. м. в год)

21,5%

3.

Амортизация оборудования,
технических средств

1,5%

3.1.

Компьютер – 20 000 руб. при сроке
службы 3 года (2-я амортизационная группа)

0,9%

3.2.

Стол – 8 000 руб. при сроке службы
7 лет (4-я амортизационная группа)

0,2%

3.3.

Стул – 2 000 руб. при сроке службы
7 лет (4-я амортизационная группа)

0,0%

3.4.

Тумба – 2 000 руб. при сроке
службы 7 лет (4-я амортизационная группа)

0,1%

3.5.

Прочие (доля от шкафов для одежды,
для документов, офисной оргтехники и т.д.) – 10 000 руб. при сроке службы 7
лет (4-я амортизационная группа)

0,2%

4.

Прочие расходы (принимаются на
уровне 15% от ФОТ)

15,0%

4.1.

· содержание и ремонт
зданий/помещений, сооружений и оборудования

4.2.

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

4.3.

· расходы на научно-техническую
информацию

4.4.

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

4.5.

· оплата бухгалтерских,
информационных, консультационных, банковских, транспортных и курьерских услуг

4.6.

· расходы на связь, средства
коммуникации, интернет

4.7.

· прочие

Стоимость работ по разработке и вводу в
промышленную эксплуатацию системы определяется из стоимости 1 человеко-месяца,
умноженного на итоговую трудоемкость работ: 135 586,84 x
1 309,03 = 177 487 241,17 руб.

2.10  Расчет экономических
показателей

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

2.10.1         Расчет ставки
дисконтирования

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

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

i = ((1 0,08305) /
(1 0,0063)) – 1 = 0,07627

Переводим годовую реальную ставку
дисконтирования в месячную:

i= (((1 (0,07627 /
100)) ^ (1/12)-1) * 100) = 0,00635

В дальнейшем ставка дисконтирования потребуется
при расчете экономических показателей эффективности.

2.10.2         Расчет экономических
показателей эффективности

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

·    Расчет срока окупаемости инвестиций
(Pay-Back Period):

Срок окупаемости показывает, в течение какого
времени окупаются вложенные в проект денежные средства с учетом изменения
стоимости денег.

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

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

·    Расчет прибыли до уплаты процентов и
налога (Operation Income):

В результате расчетов, получаем значение: Ol =
92 399,5 тыс. руб. за весь период реализации проект. Такая сумма не является
критичной, т.к. в рамках проекта нет установленного временного ограничения на
получение фиксированного минимума.

·    Расчет прибыли после уплаты налогов
и выплаты процентов по кредитам (Net Operation Income):

В результате расчетов, получаем значение: NOI=
60 185,9 тыс. руб. за весь период реализации проекта. Такое значение показателя
является удовлетворительным и соответствует положительной динамике поступления
доходов от реализации проекта.

Заключение

В данной работе приведено описание
бизнес-архитектуры, проведено анализ экономической и технической рациональности
реализации информационной системы «Автоматизированная система управления
городскими финансами», составлен специальный документ – технико-экономическое
обоснование (представлено в Приложении G).
Представлено максимально детальное описание планируемых к реализации
функциональных возможностей системы.

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

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

·  повышение эффективности деятельности органов
исполнительной власти и государственных учреждений;

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

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

Библиографическийсписок

1.Zachman J. A Framework for
Information Systems Architecture // IBM Systems Journal. 1987. Vol 16, pp 276 –
292.

.Обзор архитектуры Microsoft //
Microsoft Developer Network [Электронный ресурс] [Режим доступа:
https://msdn.microsoft.com/ru-ru/library/ee872883.aspx] [Проверено:
27.04.2021].

3.Всяких Е., Сидоренко Е., Зуева А.,
Носков Б., Киселёв С. Практика и проблематика моделирования бизнес-процессов. М:
ДМК Пресс, 2008.

.Barry Boehm. Software
engineering economics. Englewood Cliffs, NJ:Prentice-Hall, 1981. ISBN
0-13-822122-7

.Jorgen M, Sjoberg D.I.K, “The
Impact of Customer Expectation on Software Development Effort Estimates” International
Journal of Project Management, Elsevier, pp 317-325, 2004

6.Щеренкова О. Оценка экономической
эффективности инвестиционных проектов // Финансовый менеджмент – 2005 – Вып.3.

.Дамодаран А. Инвестиционная оценка.
– 2-е изд. – М.: Альпина Бизнес Букс, 2004.

.Типовые организационные структуры
предприятий // Корпоративный менеджмент [Электронный ресурс] [Режим доступа: #”896537.files/image019.jpg”>

Рисунок 1. Матричная организационная
структура

Приложение B.
Производственный план проекта

Таблица 12. Производственный план
реализации разработки АСУГФ

Наименование задачи

Сроки

Начало

Окончание

Длительность, рабочих дней

Выполнение работ по разработке и
развитию АСУ ГФ

26.05.2021

22.12.2021

148

 Этап 1. Обследование объекта
автоматизации и уточнение требований к системе

26.05.2021

15.07.2021

35

 Обследование и уточнение требований

27.05.2021

01.07.2021

25

 Уточнение требований к подсистеме
“Планирование и анализ доходной части бюджета”

27.05.2021

01.07.2021

25

 Уточнение требований к механизмам
электронного документооборота в подсистеме “Планирование и анализ
доходной части бюджета” (п. 4.2.1.1.1 ТЗ)

27.05.2021

09.06.2021

10

 Анализ и уточнение требований к
аналитическим срезам модуля “Исполнения” (п. 4.2.2.3.1 ТЗ)

27.05.2021

17.06.2021

15

 Анализ и уточнение требований к
модернизации механизмов журналирования и аудита с использованием МЦУП (п.
4.2.2.3.2 ТЗ)

01.07.2021

5

 Уточнение требований к подсистеме
АРМ руководителя ДФ Москвы

27.05.2021

24.06.2021

20

 Интервью заказчика и уточнение
требований к веб-приложению (п. 4.2.2.4.1 ТЗ)

27.05.2021

09.06.2021

10

 Интервью заказчика и уточнение
требований к мобильному приложению (п. 4.2.2.4.2 ТЗ)

10.06.2021

24.06.2021

10

 Уточнение требований к подсистеме
Аналитической обработки данных

27.05.2021

24.06.2021

20

 Уточнение реквизитного состава
паспортов открытых данных (п. 4.2.2.5.1 ТЗ)

03.06.2021

17.06.2021

10

 Анализ и уточнение требований к
формату и составу передаваемых данных (п. 4.2.2.5.1 ТЗ)

20.06.2021

24.06.2021

5

 Интервью заказчика и уточнение
перечня и требований к составу аналитических отчетов по расходам, доходам и
государственным заданиям, на основе информации, передаваемой из подсистем АСУ
ГФ и АИС УБП 1-М (п. 4.2.2.5.2 ТЗ)

27.05.2021

17.06.2021

15

 Анализ и уточнение требований к
информационному взаимодействию с ГИИС “Открытый бюджет” (п. 4.2.2.7
ТЗ)

27.05.2021

09.06.2021

10

 Анализ и детализация требований к
подсистеме Формирования и ведения бюджетных смет подведомственной сети
учреждений (п. 4.2.2.8 ТЗ)

27.05.2021

17.06.2021

15

 Интервью заказчика и уточнение
требований к аналитическим отчетным формам модуля ведения ведомственных
перечней на основе федеральных отраслевых перечней (п. 4.2.2.9 ТЗ)

10.06.2021

17.06.2021

5

 Анализ и детализация требований
подсистеме формирования госзаданий и соглашений на их фин.обеспечение (п.
4.2.2.10 ТЗ)

27.05.2021

17.06.2021

15

 Анализ и уточнение требований к
дополнительным контрольным соотношениям подсистемы СШК (п. 4.2.2.7 ТЗ)

27.05.2021

02.06.2021

5

 Анализ и уточнение требований к
информационному взаимодействию с УАИС “Бюджетный учет” (п. 4.2.2.20
ТЗ)

27.05.2021

17.06.2021

15

 Анализ и уточнение требований к
подсистеме обеспечения юридической значимости (4.2.2.21 ТЗ)

27.06.2021

01.07.2021

5

 Обеспечение информационной
безопасности

27.05.2021

01.07.2021

25

 Анализ обрабатываемых документов
и классификация ИС

27.05.2021

09.06.2021

10

 Анализ угроз и описание
потенциальных угроз и действий нарушителя ИБ ИС

10.06.2021

24.06.2021

10

 Анализ и формирование требований
по обеспечению ИБ ИС

27.06.2021

01.07.2021

5

 Документирование

04.07.2021

15.07.2021

10

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

04.07.2021

13.07.2021

8

 Описание бизнес-сценариев
автоматизируемых процессов (п. 8.1 ТЗ)

04.07.2021

13.07.2021

8

 Оформление и согласование ЧТЗ

07.07.2021

15.07.2021

7

 Этап 2. Техно-рабочий проект Системы
в рамках реализации функций первой части

16.07.2021

13.09.2021

42

 Системное проектирование

18.07.2021

11.08.2021

19

 Анализ требований и
проектирование архитектурных решений

18.07.2021

22.07.2021

5

 Анализ требований и
проектирование хранилища данных

29.07.2021

11.08.2021

10

 Анализ требований и
проектирование межкомпонентных интерфейсов

29.07.2021

11.08.2021

10

 Внедрение юридически значимого
электронного документооборота (п. 4.2.1.1 ТЗ)

25.07.2021

29.08.2021

26

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

25.07.2021

28.07.2021

4

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

05.08.2021

09.08.2021

3

 Интеграционное тестирование и
устранение ошибок

26.08.2021

29.08.2021

2

 Обеспечение возможности
применения кодов бюджетной классификации в соответствии с принципами,
установленными Федеральным законом от 22.10.2021 № 311-ФЗ (п. 4.2.1.2 ТЗ)

18.07.2021

26.08.2021

30

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

18.07.2021

20.07.2021

3

 Разработка пакета спецификаций на
реализацию требований по изменению бюджетной классификации

21.07.2021

22.07.2021

2

 Модернизация экранных и отчетных
форм системы

25.07.2021

05.08.2021

10

 Модернизация механизмов
межсистемного взаимодействия

25.07.2021

19.08.2021

20

 Интеграционное тестирование
межсистемного взаимодействия

01.08.2021

26.08.2021

20

 Развитие подсистемы планирования
и анализа доходной части бюджета города Москвы (п. 4.2.2.3 ТЗ)

29.07.2021

25.08.2021

20

 Разработка спецификации на
реализацию требований

29.07.2021

04.08.2021

5

 Модернизация программного
обеспечения подсистемы

05.08.2021

18.08.2021

10

 Модульное тестирование и
устранение ошибок

19.08.2021

25.08.2021

5

 Развитие подсистемы аналитической
обработки данных (п. 4.2.2.5 ТЗ)

18.07.2021

12.08.2021

20

 Разработка спецификации по
реализации требований

18.07.2021

29.07.2021

10

 Модернизация программного
обеспечения подсистемы

01.08.2021

05.08.2021

5

 Модульное тестирование и устранение
ошибок

08.08.2021

12.08.2021

5

 Создание модуля согласования и
утверждения ведомственных перечней, сформированных на основании федеральных
базовых (отраслевых) перечней (п. 4.2.2.9 ТЗ)

25.07.2021

02.08.2021

7

 Разработка спецификации на реализацию
требований

25.07.2021

27.07.2021

3

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

28.07.2021

29.07.2021

2

 Модульное тестирование и
устранение ошибок

01.08.2021

02.08.2021

2

 Развитие подсистемы Реестр
расходных обязательств города Москвы (п. 4.2.2.12 ТЗ)

18.07.2021

12.08.2021

20

 Разработка спецификации на
реализацию требований

18.07.2021

22.07.2021

5

 Модернизация программного
обеспечения подсистемы

25.07.2021

05.08.2021

10

 Модульное тестирование и
устранение ошибок

08.08.2021

12.08.2021

5

 Создание модуля обеспечения
информационного взаимодействия с Фондом капитального ремонта города Москвы
(п. 4.2.2.16 ТЗ)

25.07.2021

26.08.2021

25

 Разработка спецификации на
реализацию требований

25.07.2021

29.07.2021

5

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

01.08.2021

19.08.2021

15

 Модульное тестирование и
устранение ошибок

22.08.2021

26.08.2021

5

 Создание подсистемы «Обеспечения
юридической значимости» (п. 4.2.2.21 ТЗ)

29.07.2021

25.08.2021

20

 Разработка спецификации на
реализацию требований

29.07.2021

04.08.2021

5

 Разработка программного
обеспечения подсистемы

05.08.2021

18.08.2021

10

 Модульное тестирование и
устранение ошибок

19.08.2021

25.08.2021

5

 Интеграционное тестирование и
отладка

30.08.2021

05.09.2021

5

 Документирование

12.08.2021

06.09.2021

18

 Технический проект

12.08.2021

25.08.2021

10

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

12.08.2021

25.08.2021

10

 Описание архитектуры Системы

12.08.2021

25.08.2021

10

 Рабочая документация

23.08.2021

05.09.2021

10

 Общее описание Системы

26.08.2021

01.09.2021

5

 Руководство пользователя Системы

23.08.2021

05.09.2021

10

 Руководство администратора
Системы

30.08.2021

05.09.2021

5

 Программа и методика
предварительных испытаний Системы

01.09.2021

05.09.2021

3

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

01.09.2021

05.09.2021

3

 Акт ввода Системы в опытную
эксплуатацию (проект)

01.09.2021

05.09.2021

3

 Ведомость машинных носителей
информации

06.09.2021

06.09.2021

1

 Пуско-наладочные работы

06.09.2021

06.09.2021

1

 Предварительные испытания

07.09.2021

13.09.2021

5

 Этап 3. Техно-рабочий проект
Системы в рамках реализации функций второй части

14.09.2021

22.11.2021

49

 Системное проектирование

14.09.2021

25.10.2021

30

 Анализ требований и проектирование
архитектурных решений

14.09.2021

20.09.2021

5

 Анализ требований и
проектирование хранилища данных

12.10.2021

25.10.2021

10

 Анализ требований и
проектирование межкомпонентных интерфейсов

12.10.2021

25.10.2021

10

 Развитие подсистемы планирования
расходной части бюджета города Москвы (п. 4.2.2.2 ТЗ)

21.09.2021

01.11.2021

30

 Разработка спецификации на
реализацию требований

21.09.2021

04.10.2021

10

 Модернизация программного
обеспечения подсистемы

05.10.2021

25.10.2021

15

 Модульное тестирование и устранение
ошибок

26.10.2021

01.11.2021

5

 Развитие автоматизированного
рабочего места руководителя Департамента финансов города Москвы (п. 4.2.2.4
ТЗ)

14.09.2021

13.10.2021

22

 Разработка спецификации на
модернизацию “обычной” версии

14.09.2021

20.09.2021

5

21.09.2021

04.10.2021

10

 Модульное тестирование и
устранение ошибок “обычной” версии

05.10.2021

11.10.2021

5

 Разработка спецификации на
модернизацию мобильной версии

21.09.2021

04.10.2021

10

 Модернизация программного
обеспечения мобильной версии

05.10.2021

10.10.2021

4

 Модульное тестирование АРМ
руководителя и устранение ошибок

12.10.2021

13.10.2021

2

 Создание подсистемы формирования
и ведения бюджетных смет по подведомственной сети учреждений (п. 4.2.2.8 ТЗ)

21.09.2021

01.11.2021

30

 Разработка спецификации на
создание подсистемы

21.09.2021

04.10.2021

10

 Создание программного обеспечения
подсистемы

05.10.2021

25.10.2021

15

 Модульное тестирование и
устранение ошибок

26.10.2021

01.11.2021

5

 Развитие подсистемы ведения
государственных заданий (п. 4.2.2.10 ТЗ)

14.09.2021

25.10.2021

30

 Разработка спецификации на
модернизацию подсистемы

14.09.2021

27.09.2021

10

 Модернизация программного
обеспечения подсистемы

28.09.2021

18.10.2021

15

 Модульное тестирование и
устранение ошибок

19.10.2021

25.10.2021

5

 Развитие подсистемы ведения
реестра государственных, муниципальных учреждений (п. 4.2.2.11 ТЗ)

14.09.2021

14.10.2021

23

 Разработка спецификации на
модернизацию подсистемы

14.09.2021

20.09.2021

5

 Модернизация программного
обеспечения

21.09.2021

04.10.2021

10

 Модульное тестирование и
устранение ошибок

05.10.2021

11.10.2021

5

 Интеграционное тестирование АСИ
УБП-1М и устранение ошибок

12.10.2021

14.10.2021

3

 Развитие подсистемы «Сводная
бюджетная роспись» (п. 4.2.2.18 ТЗ)

21.09.2021

18.10.2021

20

 Разработка спецификации на
модернизацию подсистемы

21.09.2021

27.09.2021

5

 Модернизация программного
обеспечения подсистемы

28.09.2021

11.10.2021

10

 Модульное тестирование и
устранение ошибок

12.10.2021

18.10.2021

5

 Документирование

26.10.2021

15.11.2021

14

 Технический проект

26.10.2021

01.11.2021

5

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

26.10.2021

01.11.2021

5

 Описание архитектуры Системы

26.10.2021

01.11.2021

5

 Рабочая документация

26.10.2021

15.11.2021

14

 Общее описание Системы

26.10.2021

01.11.2021

5

 Руководство пользователя Системы

02.11.2021

14.11.2021

8

 Руководство администратора
Системы

10.11.2021

15.11.2021

4

 Программа и методика
предварительных испытаний Системы

10.11.2021

14.11.2021

3

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

14.11.2021

15.11.2021

2

 Акт ввода Системы в опытную
эксплуатацию (проект)

14.11.2021

15.11.2021

2

 Ведомость машинных носителей
информации

14.11.2021

14.11.2021

1

 Пуско-наладочные работы

14.11.2021

14.11.2021

1

 Предварительные испытания

16.11.2021

22.11.2021

5

 Этап 4. Опытная эксплуатация и
приемка Системы

14.09.2021

22.12.2021

71

 Обучение и консультация персонала
Системы по новым компонентам

14.09.2021

15.12.2021

66

 Техническое и сервисное
сопровождение новых компонент Системы

14.09.2021

15.12.2021

66

 Проведение SEO оптимизации
портала “Открытый бюджет”

14.09.2021

15.12.2021

66

 Анализ и устранение ошибок,
выявленных в ходе опытной эксплуатации

14.09.2021

15.12.2021

66

 Документирование

14.09.2021

15.12.2021

66

 План-программа подготовки
персонала

14.09.2021

20.09.2021

5

 Отчет о подготовке персонала

09.12.2021

15.12.2021

5

 Акт о проведении подготовки
персонала

09.12.2021

15.12.2021

5

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

14.09.2021

15.12.2021

66

 Акт о завершении опытной
эксплуатации

09.12.2021

15.12.2021

5

 Программа и методика комплексных
приемочных испытаний

13.12.2021

15.12.2021

3

 Акт о готовности системы к промышленной
эксплуатации

13.12.2021

15.12.2021

3

 Комплексные приемочные испытания

16.12.2021

22.12.2021

5

 Проектный офис

27.05.2021

22.12.2021

148

 Общее управление проектом

27.05.2021

22.12.2021

148

 Координация проектной команды

27.05.2021

22.12.2021

148

 Администрирование проекта

27.05.2021

22.12.2021

148

ИТОГО:

27.05.2021

22.12.2021

148

27.05.2021

22.12.2021

148

Приложение C.
Модель, иллюстрирующая 1 уровень декомпозиции бизнес-процессов

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт

Рисунок 2. Value Added Chain Diagram (1)

Приложение D.
Модель, иллюстрирующая 2 уровень декомпозиции бизнес-процессов

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт

Рисунок 3.Value Added Chain Diagram (2)

Приложение E. Модель,
иллюстрирующая бизнес-процесс разработки системы

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт

Рисунок 4. Extended Event driven Process Chain
Diagram (фрагмент
1)

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт

Рисунок 5. Extended Event driven Process Chain
Diagram (фрагмент
2)

Приложение F.
Модель, иллюстрирующая окружение бизнес-процесса разработки системы

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт

Рисунок 6. Function Allocation Diagram

Приложение G.Технико-экономическое обоснование

УТВЕРЖДАЮ Государственный
заказчик:

СОГЛАСОВАНО Исполнитель:

ДЕПАРТАМЕНТ ИНФОРМАЦИОННЫХ
ТЕХНОЛОГИЙ

ВЫПОЛНЕНИЕ
НАУЧНО-ИССЛЕДОВАТЕЛЬСКИХ И ОПЫТНО-КОНСТРУКТОРСКИХ РАБОТ

ПО СОЗДАНИЮ АВТОМАТИЗИРОВАННОЙ
СИСТЕМЫ УПРАВЛЕНИЯ ГОРОДСКИМИ ФИНАНСАМИ

АСУ ГФ

Технико-экономическое
обоснование

На 27
листах

2021
г

Оглавление

1. ВВЕДЕНИЕ

1.1
Основание для проведения работ

.2
Наименование организации-заказчика

.3
Наименование организаций – участников работ

.4
Сроки начала и окончания работ

.5
Источники, объемы, порядок финансирования работ

.
ХАРАКТЕРИСТИКА ОБЪЕКТА И СУЩЕСТВУЮЩЕЙ СИСТЕМЫ УПРАВЛЕНИЯ

.1 Общая
характеристика объекта

.2
Характеристика производственно-хозяйственной деятельности

.3
Перечень и характеристика недостатков

. ЦЕЛИ
СОЗДАНИЯ АСУ ГФ

.1
Назначение информационной системы

.2
Цели и задачи разработки информационной системы

.
ФУНКЦИИ СОЗДАВАЕМОЙ АСУ ГФ

.1
Перечень реализуемых функций

.3.
Требования к перспективам развития

5.
ОЖИДАЕМЫЕ ТЕХНИКО-ЭКОНОМИЧЕСКИЕ РЕЗУЛЬТАТЫ СОЗДАНИЯ

5.1
Расчет оценки стоимости разработки информационной системы

.1
Расчет экономических показателей

5.1.1
Расчет ставки дисконтирования

.1.2
Расчет экономических показателей эффективности

6. ВЫВОДЫ

1.      ВВЕДЕНИЕ

1.1    Основание для проведения работ

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

.Приказ Министерства финансов Российской
Федерации от 08 июня 2021 г. № 90н «О внесении изменений в Указания о порядке
применения бюджетной классификации Российской Федерации, утвержденные приказом
Министерства финансов Российской Федерации от 1 июля 2021 г. № 65н».

.Приказ Министерства финансов Российской
Федерации от 22 сентября 2021 г. № 145н «Об утверждении Методических
рекомендаций по представлению бюджетов субъектов Российской Федерации и местных
бюджетов и отчетов об их исполнении в доступной для граждан форме».

.Распоряжение Правительства Российской Федерации
от 30 декабря 2021 г. № 2593-р «Об утверждении Программы повышения
эффективности управления общественными (государственными и муниципальными)
финансами на период до 2021 года» о разработке информационных подсистем
управления государственными и муниципальными финансами публично-правовых
образований и организаций сектора государственного управления.

.Постановление Правительства от 9 августа 2021
г. № 349-ПП «Об утверждении государственной программы «Информационный город» на
2021-2021 годы» (в ред. Постановления Правительства от 01.12.2021 №814-ПП).

.1.Подпрограмма 12.02.000.000.00. Повышение
эффективности реализации функций органами исполнительной власти за счет
внедрения информационно-коммуникационных технологий.

.1.1.Мероприятие 12.02.002.000.00. Повышение
эффективности системы управления финансовой и экономической деятельностью за
счет внедрения информационно-коммуникационных технологий.

1.2 Наименование организации-заказчика

Государственный заказчик работ: Департамент
информационных технологий.

Функциональный заказчик работ: Департамент
финансов города Москвы.

1.3 Наименование
организаций – участников работ

Исполнитель работ определяется на конкурсной
основе в соответствии с действующим законодательством.

.4 Сроки начала и окончания работ

Начало окончание работ определяются в
соответствии с условиями конкурсной документации.

.5 Источники, объемы, порядок финансирования
работ

Источником финансирования работ является бюджет
города Москвы.

. ХАРАКТЕРИСТИКА ОБЪЕКТА И СУЩЕСТВУЮЩЕЙ СИСТЕМЫ
УПРАВЛЕНИЯ

.1 Общая характеристика объекта

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

Свою деятельность в рамках реализации бюджетного
процесса Департамент финансов осуществляет в соответствии с постановлением от
22 февраля 2021 г. № 43-ПП «Об утверждении Положения о Департаменте финансов».

Порядок организационного, документационного,
информационного обеспечения деятельности Департамента финансов определяет
«Регламент Департамента финансов» (Приложение к Приказу Департамента финансов
от 23 апреля 2009 г. № 58, в редакции приказов Департамента финансов от 28
сентября 2009 г. № 108 и от 13 июля 2021 г. № 133).

Распределение ответственности между структурными
подразделениями Департамента Финансов за предоставление показателей по разделам
и подразделам классификации расходов бюджета, по главным распорядителям бюджетных
средств, по государственным программам, по источникам финансирования дефицита
бюджета определяет Приказ Департамента финансов № 36 «Об утверждении перечней
ответственных структурных подразделений Департамента финансов».

Этапы составления бюджета регламентированы
постановлением от 14 февраля 2021 г. № 42-ПП «Об утверждении Положения о
составлении проектов бюджета города и бюджета городского фонда обязательного
медицинского страхования на очередной финансовый год и плановый период».

.2 Характеристика производственно-хозяйственной
деятельности

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

Читайте также:  Как подать декларацию 3-ндфл через госуслуги 2020 - как сдать, через интернет, подача, можно ли - Жилищный эксперт

.3 Перечень и характеристика недостатков

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

Однако до настоящего времени:

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

•не осуществлена полная автоматизация с
последующей интеграцией всех процессов управления финансово-хозяйственной
деятельности организаций;

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

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

3. ЦЕЛИ СОЗДАНИЯ АСУ ГФ

3.1 Назначение информационной системы

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

.информационно-аналитической поддержке процесса
формирования доходной и расходной части бюджета;

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

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

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

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

Пользователями системы в плановом периоде
являются органы исполнительной власти, в т.ч.:

.финансовый орган – Департамент финансов;

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

.главные распорядители бюджетных средств (далее
ГРБС), распорядители бюджетных средств, главные администраторы доходов бюджета.

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

.2 Цели и задачи разработки информационной
системы

Основными целями разработки системы являются:

•повышение эффективности процесса подготовки
расходной и доходной части проекта бюджета;

•повышение открытости и прозрачности бюджета;

•повышение качества контроля бюджетного
процесса;

•повышение эффективности формирования и контроля
исполнения планов финансово-хозяйственной деятельности учреждений;

Основными индикаторами достижения поставленных
целей являются:

.перевод электронных документов, участвующих в
формировании доходной и расходной частях бюджета, на электронный
документооборот;

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

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

Основными решаемыми задачами в процессе
разработки системы являются:

•внедрение юридически значимого электронного
документооборота в части формирования органами государственной власти прогнозов
поступления доходов и источников финансирования дефицита бюджета, кассового
плана доходов и источников финансирования дефицита бюджета;

•создание подсистем информационной системы
«Автоматизированная система управления городскими финансами»;

•обеспечение возможности применения кодов
бюджетной классификации в соответствии с принципами, установленными Федеральным
законом от 22.10.2021 № 311-ФЗ.

. ФУНКЦИИ СОЗДАВАЕМОЙ АСУ ГФ

4.1 Перечень реализуемых функций

Функциональные возможности, требуемые к
реализации со стороны Исполнителя по разработке подсистемы «Планирование
расходной части бюджета»:

•  формирование бюджетных ограничений;

•        вариантное планирование расходной части
бюджета;

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

1. Модуль формирования бюджетных
ограничений.

Модуль должен обеспечивать реализацию следующих
возможностей:

–       определение бюджетных ограничений
для проекта бюджета;

–       определение бюджетных ограничений в
автоматизированном режиме:

ведение дополнительных классификаторов.
(Исполнитель должен обеспечить первоначальное наполнение дополнительных
классификаторов на основании информации, предоставленной Заказчиком);

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

ü    индексация расходов в соответствии с
настроенными правилами, ведение и учет исключений из правил индексирования;

ü  ввод корректировочных поправок –
ввод экспертных корректировок для увеличения / сокращения объемов бюджетных
ассигнований;

–       ручной ввод бюджетных ограничений;

–       подготовка отчетности и
аналитических материалов на основании информации модуля.

2. Модуль вариантного планирования
расходной части бюджета.

Модуль должен обеспечивать реализацию следующих
возможностей:

–       подготовка неограниченного числа
версий проекта бюджета – при этом новая версия проекта бюджета должна
создаваться только после утверждения предыдущей (последовательно);

–       ввод данных по проекту бюджета с учетом
бюджетных ограничений;

–       отправка ГРБС данных по проекту
бюджета, изменениям в проект бюджета на согласование в адрес Департамента
финансов;

–       согласование либо возврат на доработку
сотрудником Департамента финансов данных по проекту бюджета, изменениям в
проект бюджета в адрес ГРБС;

–       утверждение версии проекта бюджета;

–       подготовка приложений к закону о
бюджете по расходам.

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

Функциональная возможность должна обеспечивать
реализацию:

–       Методического обеспечения в части
планирования межбюджетных трансфертов;

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

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

–       обследование правового регулирования
и практики предоставления межбюджетных трансфертов за 2021-2021 годы, выявить
сильные и слабые стороны организации предоставления межбюджетных трансфертов;

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

–       формирование предложений в части
расчета межбюджетных трансфертов, в т.ч. в части:

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

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

правового регулирования предоставления субвенций
для осуществления переданных органам местного самоуправления отдельных
государственных полномочий;

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

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

о внесении изменений и дополнений в Закон от
10.09.2008 № 39 «О бюджетном устройстве и бюджетном процессе»;

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

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

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

–       отображение перечня межбюджетных
трансфертов;

–       формирование расчета межбюджетных
трансфертов, в т.ч.:

ручной ввод исходных данных (данные,
используемые для расчетов) в разрезе муниципальных образований;

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

–       формирование приложений к закону о
бюджете в части межбюджетных трансфертов в формате Excel.

Внедрение программного принципа на
местном уровне.

Назначением модуля должно являться обеспечение
следующих возможностей:

–       методическое обеспечение в части
внедрения программного принципа на местном уровне;

–       прототип программного обеспечения по
представлению местных бюджетов в программном виде.

Методическое обеспечения в части внедрения
программного принципа на местном уровне должно обеспечивать:

–       разработку подходов к организации
комплексного внедрения программного принципа на местном уровне;

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

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

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

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

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

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

–       формирование программ органа местного
самоуправления (далее – ОМСУ), в т.ч.:

определение состава программ (добавление,
удаление программы из перечня);

определение структуры программы;

ввод информации по разделам программы (паспорт,
показатели, финансирование и др.);

–       ввод сведений о реализации программ
ОМСУ (показатели, финансирование);

–       формирование отчетности в формате
Excel:

регламентного отчета по программе;

сводного отчета по всем программам ОМСУ;

отчета об исполнении программы.

Мониторинг исполнения местных
бюджетов и оценка качества финансового менеджмента:

Назначением модуля должно являться обеспечение
следующих возможностей:

–       Разработка методического обеспечения
в части внедрения на муниципальном уровне оценки качества финансового
менеджмента на муниципальном уровне;

–       Прототип программного обеспечения по
проведению оценки качества финансового менеджмента на муниципальном уровне;

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

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

–       разработку подходов к внедрению на
муниципальном уровне оценки качества финансового менеджмента;

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

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

Функциональные возможности, требуемые к
реализации со стороны Исполнителя по разработке подсистемы «Планирование и
анализ доходной части бюджета»:

•  вариантное планирование расходной доходной
бюджета.

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

Подсистема «Автоматизированное рабочее место
руководителя Департамента финансов» предназначена для визуализации информации о
бюджете, а также предоставления руководителю Департамента финансов функций
мобильного офиса.

В рамках выполнения работ по разработке
веб-приложения должны быть разработаны механизмы:

–    формирования и вывода на печать графика
мероприятий;

–       выгрузки экранных форм в файлы
форматов Adobe
PDF и MS
Excel;

–       разграничения прав пользователей,
позволяющие выдавать разрешения на редактирование определённых разделов;

–       журналирования
действий пользователей.

Исполнителем также должны быть разработаны
инструменты:

–    согласования пакетов документов на внесение
изменений в сводную бюджетную роспись с использованием электронной подписи;

–       ввода и отображения еженедельной
отчетной информации по государственному долгу;

–       ввода и отображения информации по
исполнению доходной части бюджета;

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

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

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

·  реализация механизма подписания электронных
документов юридически значимой электронной подписью;

·        реализация механизма проверки
открытой части ключа электронной подписи (далее ЭП);

·        реализация механизма проверки
электронной подписи;

·        реализация механизма включения
штампа времени в ЭП;

Подсистема «Аналитической обработки данных»
должна быть предназначена для консолидации информации о бюджетном процессе и
социально-экономическом развитии.

В рамках выполнения работ по развитию подсистемы
должны быть разработаны:

·  механизмы ведения реестра открытых данных
Департамента финансов и передача их на «Портал открытых данных Правительства»;

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

.2 Требования к перспективам развития

Проектные решения, применяемые при разработке
первой очереди АСУ ГФ, должны обеспечивать возможность дальнейшего развития и
модернизации как программного обеспечения, так и комплекса технических средств.

При разработке должны быть предусмотрены:

•возможность увеличения производительности
системы путем её масштабирования;

•увеличение количества систем, участвующих в
информационном взаимодействии.

5.      ОЖИДАЕМЫЕ ТЕХНИКО-ЭКОНОМИЧЕСКИЕ
РЕЗУЛЬТАТЫ СОЗДАНИЯ

5.1.   Расчет оценки стоимости разработки
информационной системы

В качестве основы расчета оценки стоимости разработки
информационной системы была выбрана модель – COCOMO
II. Согласно
описываемой модели расчёты должны осуществляться следующим образом:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (1)

где

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

Size – сумма
строк кода, представленная в тыс. строк (KSLOC).

EMi – множители трудоемкости
разработки.

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (2)

где

B – коэффициент
зависимости трудозатрат от степени масштабируемости проекта, полученный путем
обработки информации по большому количеству проектов за длительный промежуток
времени.

SF – факторы,
отражающих особенности проекта и коллектива разработчиков.

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

Входными параметрами для расчета трудоемкости
являются:

·  количество строк кода, подсчитанное исходя из
оценки User Function Types (логических групп данных, которые используются и
поддерживаются системой, и функциональности совершаемых транзакций);

·        интегральная оценка масштабируемости
проекта;

·        интегральные множители трудоемкости.

Вычисление Size(количество
строк кода, выраженное в тысячах
строк):

Для вычисления количество строк кода по модели COCOMO-II
необходимо произвести оценку User
Function
Types (логических групп
данных и функциональности совершаемых транзакций в системе), после чего,
согласно таблице весов (Model
Definition
Manual), определить
ненормированное количество функциональных точек (Unadjusted
Function
Point, UFP).
Далее для предполагаемого языка программирования следует определить коэффициент
отношения строчек кода к UFP
(Model Definition
Manual) и на основании
данного коэффициента и числа UFP
подсчитать Size.

Общая функциональность определяется
путем:

3.   Анализа логических групп данных, которые
используются и поддерживаются системой (точки типа ILF
и EIF):

·        ILF
– Internal
Logical File
– внутренний логический файл (логически связанная группа данных, определяемая
пользователем и находящаяся внутри границ проекта).

·        EIF
– External
Interface
Files – внешний
интерфейсный файл (логически связанная группа данных, обеспечивающая
программное обеспечение информацией, но лежащая за его пределами и
поддерживаемая другим программным обеспечением).

4.   Анализа функциональности совершаемых
транзакций (точки типа EInp, EO и EInq):

·        EInp
– External
Input – внешний вход
(процесс ввода данных и управляющей информации).

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

·        EInq
– External
Inquiry – внешний запрос
(диалоговый ввод, который приводит к немедленному ответу ПС в форме диалогового
вывода).

Итоговое количество функциональных точек в
системе представлено в Таблица1. Оно
составляет 4 027,5 ед.

Таблица 1. Количество User Function Types в
системе

Тип

Всего

Из них по уровню сложности

Весовые коэффициенты уровней
сложности по модели COCOMO-II

Ненормированное количество
функциональных точек (Unadjusted
Function
Point)

Низкий

Средний

Высокий

Низкий

Средний

Высокий

ILF

142,0

58,0

17,0

67,0

3,0

4,0

6,0

644,0

EIF

79,0

25,0

12,0

42,0

4,0

5,0

7,0

454,0

EInp

165,0

66,0

47,0

52,0

7,0

10,0

15,0

1 712,0

EO

107,9

43,9

22,0

42,0

5,0

7,0

10,0

793,5

EInq

97,0

38,0

22,0

37,0

3,0

4,0

6,0

424,0

Всего

590,9

4 027,5

На основе данных, полученных из инструкции Model
Definition
Manual к модели COCOMO-II,
коэффициент UFP для языка Java
(Eclipse), на котором в
плановом периоде будет реализована большая часть подсистем составляет 53.

Таким образом, число строк кода составляет 4
027,5
x 53 = 213457,5,
а переменная Size,
(количество строк кода, выраженная в тысячах строк) – 213, 46.

Вычисление Е – интегральной оценки
масштабируемости проекта:

Методика COCOMO
II позволяет оценить
влияние масштабов проекта на эффективность процесса разработки программного
продукта. Данная зависимость в формуле расчета трудоемкости оценивается
коэффициентом масштаба E.

Е – интегральная оценка масштабируемости проекта
рассчитывается на основании оценки факторов масштаба и имеет вид:

ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт (3)

где

B – коэффициент
зависимости трудозатрат от степени масштабируемости проекта, полученный путем
обработки информации по большому количеству проектов за длительный промежуток
времени.

SF – факторы,
отражающих особенности проекта и коллектива разработчиков.

В Таблица 2 представлена оценка состояния
масштабирующих факторов, проведенная на основе значений, полученных с помощью
использования инструкции Model
Definition
Manual созданной специально
для COCOMO-II.

Таблица 2. Перечень параметров масштабируемости
системы

IND

Название

Состояние

Знач.

PREC

Прецедентность

Продукт и платформа в целом
изучены

1,24

FLEX

Гибкость процесса
разработки

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

3,04

RESL

Разрешение рисков

Часть рисков
разрешена

4,24

TEAM

Сработанность
команды

Коммуникативные
проблемы существуют

3,29

PMAT

Зрелость
процессов

Уровень 3 (выше
среднего)

3,12

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

,91 0,01 x
(1,24 3,04 4,24 3,29 3,12) = 1,059 ед.

Вычисление EMi
– множителей трудоемкости:

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

В Таблица 3 приведена оценка состояния
множителей трудоемкости, значений EMi,
полученных на основе данных технического задания и инструкции Model
Definition
Manual к модели COCOMO-II.

Таблица 3. Оценка множителей трудоемкости

IND

Название

Состояние

Знач.

RELY

Требуемая
надежность

Номинальный.
Имеются незначительные неудобства

1,00

DATA

Размер тестовых
данных

D/P >= 1000

1,28

CPLX

Сложность
продукта

Высокая

1,17

RUSE

Возможность использования продукта
в дальнейших разработках

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

1,15

DOCU

Полнота
документации

Соответствует
требованиям к документации

1,00

TIME

Ограничения по доступности
программной среды

Ограничение 50% и менее от общего
доступного времени 1,00

1,00

STOR

Ограничение
памяти

Занято до 50% доступного
ресурса

1,00

PVOL

Платформа
разработки

Минимальная частота изменения – 2
месяца; Максимальная частота изменения – 1 неделя.

1,15

ACAP

Квалификация
аналитиков

75%

0,85

PCAP

Квалификация
разработчиков

55%

1

PCON

Проектная команда

12% в год

1,00

APEX

Опыт разработки
приложений

6 лет и более

0,81

PLEX

Знание платформы

6 лет и более

0,85

LTEX

Знание языка и среды разработки

6 лет и более

0,84

TOOL

Среда разработки

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

1,0

SITE

Распределенная
разработка (SITE)

Разработка распределена в разных
городах и компаниях. Использование
телефонов, факсов

1,09

SCED

Корректировка
графика (SCED)

75%

1,43

Итого ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт 1,518 ед.

Итоговый расчет трудоемкости
разработки системы:

Трудоемкость проекта в человеко-месяцах в
соответствии с моделью COCOMO
II равна: PM
= 2, 94 x 213,461,0593 x
1,518 = 1 309,03 ед.

Для определения стоимости разработки системы
требуется вычислить стоимость единицы трудоемкости (см. Таблица 4)

Таблица 4. Перечень расходов, составляющих
стоимость единицы трудоемкости

Статья

Сумма, руб. на 1 специалиста в
месяц

% от СС

% от стоимости 1
человеко-месяца

1

Зарплата основных специалистов
(ФОТ) (Мосгорстат, январь-май 2021)

58 052,90

49%

43%

2

Страховые взносы в ПФ, ФМС, ФСС
(30,2%)

17 415,87

15%

13%

3

Накладные расходы
(73% от ФОТ)

42 432,83

36%

31%

4

Итого расходы
(себестоимость (СС))

117 901,60

100%

87%

5

Прибыль (15% на
итого расходы)

17 685,24

15%

13%

6

Стоимость 1 человеко-месяца, без
НДС

135 586,84

115%

100%

7

Стоимость 1 человеко-дня, без НДС

6 587,21

Стоимость 1 человеко-дня вычисляется как
стоимость 1 человеко-месяца умноженная на 12 (количество месяцев в году) и
деленная на 247 (количество рабочих дней в 2021 году).

Среднемесячная заработная плата работников за
январь-май 2021 года по полному кругу организаций, на основе данных Мосгорстата
по виду деятельности «Разработка программного обеспечения и консультирование в
этой области» составляет в среднем 58 052,90 руб.

Расчет суммарного размера тарифов страховых
взносов в 2021 году, представленный в табличном формате – Таблица 5.

Таблица 5. Страховые взносы в ПФ, ФМС, ФСС

Наименования
тарифов страховых взносов

Ставка на 2021
год, %

1

Тариф страховых взносов,
уплачиваемых в Пенсионный фонд РФ

22,0%

2

Тариф страховых взносов,
уплачиваемые в Фонд социального страхования РФ

2,9%

3

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

3,1%

4

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

2,0%

5

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

6

ИТОГО суммарный размер тарифов
страховых взносов в 2021 г.

30,2%

Расчет размера накладных расходов в % от фонда
оплаты труда, представленный в табличном формате – Таблица 6.

Таблица 6. Полный перечень накладных расходов на
реализацию проекта

Статьи накладных расходов / % от
фонда оплаты труда

Сумма

1.

Административно-управленческие
расходы (норма управляемости = 1 непосредственный руководитель на 7
специалистов с ЗП в 1,5 раз выше 1 высший руководитель, с учетом страховых
взносов)

34,9%

2.

Аренда (или амортизация
собственных) зданий/помещений (минимальный норматив 4,5 кв. м. на 1 человека,
умноженный на 2 для учета помещений общего пользования и администрации, при
ставке 40 000 руб./кв. м. в
год)

21,5%

3.

Амортизация
оборудования, технических средств

1,5%

3.1.

Компьютер – 20
000
руб. при сроке службы 3 года (2-я амортизационная группа)

0,9%

3.2.

Стол – 8
000
руб. при сроке службы 7 лет (4-я амортизационная группа)

0,2%

3.3.

Стул – 2
000
руб. при сроке службы 7 лет (4-я амортизационная группа)

0,0%

3.4.

Тумба – 2
000
руб. при сроке службы 7 лет (4-я амортизационная группа)

0,1%

3.5.

Прочие (доля от шкафов для одежды,
для документов, офисной оргтехники и т.д.) – 10 000
руб. при сроке службы 7 лет (4-я амортизационная группа)

0,2%

4.

Прочие расходы (принимаются на
уровне 15% от ФОТ)

15,0%

4.1.

· содержание и ремонт
зданий/помещений, сооружений и оборудования

4.2.

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

4.3.

· расходы на научно-техническую
информацию

4.4.

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

4.5.

· оплата бухгалтерских,
информационных, консультационных, банковских, транспортных и курьерских услуг

4.6.

· расходы на связь, средства
коммуникации, интернет

4.7.

· прочие

Стоимость работ по разработке и вводу в
промышленную эксплуатацию системы определяется из стоимости 1 человеко-месяца,
умноженного на итоговую трудоемкость работ: 135 586,84
x 1
309,03
= 177
487
241,17
руб.

5.1.   Расчет экономических показателей

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

.1.1   Расчет ставки дисконтирования

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

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

i = ((1 0,08305) /
(1 0,0063)) – 1 = 0,07627

Переводим годовую реальную ставку
дисконтирования в месячную:

i= (((1 (0,07627 /
100)) ^ (1/12)-1) * 100) = 0,00635

В дальнейшем ставка дисконтирования потребуется
при расчете экономических показателей эффективности.

5.1.2 Расчет экономических показателей
эффективности

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

·    Расчет срока окупаемости инвестиций
(Pay-Back Period):

Срок окупаемости показывает, в течение какого
времени окупаются вложенные в проект денежные средства с учетом изменения
стоимости денег.

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

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

·    Расчет прибыли до уплаты процентов и
налога (Operation Income):

В результате расчетов, получаем значение: Ol =
92 399,5 тыс. руб. за весь период реализации проект. Такая сумма не является
критичной, т.к. в рамках проекта нет установленного временного ограничения на
получение фиксированного минимума.

·    Расчет прибыли после уплаты налогов
и выплаты процентов по кредитам (Net Operation Income):

В результате расчетов, получаем значение: NOI=
60 185,9 тыс. руб. за весь период реализации проекта. Такое значение показателя
является удовлетворительным и соответствует положительной динамике поступления
доходов от реализации проекта.

6. ВЫВОДЫ

Разработка и внедрение АСУ ГФ будет
способствовать созданию:

•инструментов повышения эффективности управления
деятельностью ОИВ, основанных на программно-целевом принципе организации их
деятельности

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

•единой методологии управления государственными
финансами г. Москвы

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

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

С учётом заявленных целей представляется
возможным оценить эффект реализации мероприятий по следующим основным направлениям:

•повышение эффективности деятельности органов
исполнительной власти и государственных учреждений г. Москвы

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

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

Аннотация

Выпускная квалификационная работа на тему
«Технико-экономическое обоснование разработки информационной системы «Автоматизированная
система управления городскими финансами» написана в соответствии с учебным
планом факультета «Бизнес-информатика» Пермского филиала федерального
государственного автономного образовательного учреждения высшего
профессионального образования «Национальный исследовательский университет
“Высшая школа экономики”, утвержденным в Государственном образовательном
стандарте высшего профессионального образования «Направление 080500.62.
Бизнес-информатика».

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

Автор: Базлова Мария Геннадьевна.

Факультет бизнес-информатики. 4 курс. 2021 г.

Объем работы: 87 стр.

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

Преимущества

  • Интерактивная доступность к информационным системам всех зарегистрированных пользователей вне зависимости от их территориальной удаленности от центров хранения и обработки данных.
  • Однократность ввода информации и обеспечение её обработки в режиме реального времени.
  • Легитимность и юридическая значимость электронного документооборота в сфере управления общественными финансами всего региона.
  • Централизованное взаимодействие с федеральными реестрами и порталами.
  • Бесперебойность и надежность функционирования информационных систем с организацией многоуровневой защиты информации.

В состав АСУ ГФ региона входят направления:

1. Интеграция и автоматизация процессов управления общественными финансами:

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

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

3. Использование единых реестров и классификаторов.

4. Централизованное взаимодействие с федеральными реестрами и порталами.

5. Обеспечение прозрачности и публичности информации о деятельности публично-правовых образований в сфере управления общественными финансами (портал «Открытый бюджет»).

6. Оптимизация бюджетных расходов на использование и поддержку ИТ-решений.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector