Автоматизированная система управления городскими финансами
Описание и анализ подходов к описанию бизнес-архитектуры. Стандарты составления технико-экономического обоснования. Разработка документа, удостоверяющего рациональность создания и развития автоматизируемой системы управления городскими финансами.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 21.09.2016 |
| Размер файла | 1,3 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
4.
Прочие расходы (принимаются на уровне 15% от ФОТ)
· содержание и ремонт зданий/помещений, сооружений и оборудования;
· содержание и обслуживание программных и технических средств;
· расходы на связь, средства коммуникации, интернет;
· прочие.
4.1.
·
4.2.
·
4.3.
·
4.4.
·
Амортизационные группы определены по государственному классификатору.
2.6 Организационный план
Для проектирования деятельности рабочей группы с максимальной эффективностью необходимо построить корректную организационную структуру.
Существует шесть основных типов организационных структур:
1. линейная;
2. функциональная;
3. линейно-функциональная;
4. матричная;
5. дивизиональная;
6. множественная.
Линейной структуре соответствует наличие руководителя во главе каждого подразделения. Данный руководитель в рамках подразделения наделен всеми полномочиями для руководства работниками, находящимися в его подчинении.
Для функциональной структуры характерно разделение организации на отдельные функциональные компоненты со своими определенными обязанностями (производство, продажи, финансы и т.д.).
Линейно-функциональная организационная структура управления предполагает интеграцию вышеперечисленных структур. При этом у сотрудника есть линейный руководитель, осуществляющий мониторинг, и функциональный руководитель, который консультирует по вопросам решения задач сотрудника.
Матричная организационная структура управления в основном формируется для разработки нового проекта: создается временное подразделение - проектная группа/команда. В состав такой функциональной единицы входят и исполнители, и управленцы. Когда проект завершается, сотрудники переходят в другую (новую) проектную группу. В случае отсутствия новых проектов сотрудники возвращаются к выполнению обычных обязанностей.
Для дивизиональной структуры предполагается деятельность отделенных друг от друга подразделений (предприятий), каждое из которых является обособленным и имеет свою сферу деятельности. При этом все подразделения объединены в одну сеть с общим центральным аппаратом управления.
Под множественной структурой понимают комбинации различных структур на разных ступенях управления. Например, для головной компании может применяться линейная структура управления, а в филиалах - матричная [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.2016 |
15.07.2016 |
35 |
|
|
Этап 2. Техно-рабочий проект Системы в рамках реализации функций первой части |
16.07.2016 |
13.09.2016 |
42 |
|
|
Этап 3. Техно-рабочий проект Системы в рамках реализации функций второй части |
14.09.2016 |
22.11.2016 |
49 |
|
|
Этап 4. Опытная эксплуатация и приемка Системы |
14.09.2016 |
22.12.2016 |
71 |
Первый этап «Обследование объекта автоматизации и уточнение требований к системе» содержит подзадачи:
1. Обследование и уточнение требований:
1.1. Уточнение основных требований к подсистеме «Планирование и анализ доходной части бюджета».
1.2. Уточнение основных требование к подсистеме «Планирование расходной части бюджета».
1.3. Уточнение основных требований к подсистеме «Автоматизированное рабочее место руководителя Департамента финансов».
1.4. Уточнение основных требований к подсистеме аналитической обработки данных.
1.5. Анализ и уточнение основных требований к информационному взаимодействию подсистем.
2. Обеспечение информационной безопасности (далее ИБ):
2.1. Анализ обрабатываемых документов и классификация.
2.2. Анализ угроз и описание потенциальных угроз и действий нарушителя ИБ.
2.3. Анализ и формирование требований по обеспечению ИБ.
3. Документирование:
3.1. Оформление и согласование отчета об обследовании.
3.2. Описание бизнес-сценариев автоматизируемых процессов.
3.3. Оформление и согласование частного технического задания.
Длительность первого этапа составляет 35 рабочих дней. В работе над проектом в рамках данного этапа помимо руководителей задействованы: главные аналитики, аналитики, технические писатели.
Второй этап «Техно-рабочий проект системы в рамках реализации функций первой части» более объемный и содержит подзадачи:
1. Системное проектирование.
2. Внедрение юридически значимого электронного документооборота:
3. Обеспечение возможности применения кодов бюджетной классификации в соответствии с принципами, установленными Федеральным законом от 22.10.2014 № 311-ФЗ.
4. Разработка подсистемы «Планирование и анализ доходной части бюджета».
5. Разработка подсистемы «Планирование расходной части бюджета».
6. Разработка подсистемы «Автоматизированное рабочее место руководителя Департамента финансов».
7. Создание модуля согласования и утверждения ведомственных перечней, сформированных на основании федеральных базовых (отраслевых) перечней.
8. Создание модуля формирования предложений по распределению предельных объемов бюджетных ассигнований.
9. Создание модуля обеспечения информационного взаимодействия с Фондом капитального ремонта.
10. Создание подсистемы «Обеспечения юридической значимости».
11. Интеграционное тестирование и отладка.
12. Документирование:
12.1. Технический проект:
12.1.1. Пояснительная записка к техническому проекту системы.
12.1.2. Описание архитектуры системы.
12.2. Рабочая документация:
12.2.1. Общее описание системы.
12.2.2. Руководство пользователя системы.
12.2.3. Руководство администратора системы.
12.2.4. Программа и методика предварительных испытаний.
12.2.5. Программа опытной эксплуатации системы.
12.2.6. Акт ввода системы в опытную эксплуатацию (проект).
12.3. Ведомость машинных носителей информации.
13. Пуско-наладочные работы.
14. Предварительные испытания.
Длительность второго этапа составляет 42 рабочих дня. В работе над проектом в рамках данного этапа помимо руководителей задействованы все участники проектной команды: главные аналитики, аналитики, технические писатели, разработчики, тестеры и др.
Третий этап «Техно-рабочий проект системы в рамках реализации функций второй части» по объему работ близок похож на второй и содержит подзадачи:
1. Системное проектирование
2. Развитие подсистемы «Планирование расходной части бюджета».
3. Развитие подсистемы «Планирование и анализ доходной части бюджета».
4. Развитие подсистемы «Автоматизированное рабочее место руководителя Департамента финансов».
5. Реализация информационного взаимодействия с информационной системой «Электронный бюджет».
6. Создание подсистемы аналитической обработки данных.
7. Развитие подсистемы «Обеспечения юридической значимости».
8. Разработка подсистемы «Сводная бюджетная роспись».
9. Развитие модуля обеспечения информационного взаимодействия с Фондом капитального ремонта.
10. Развитие модуля формирования предложений по распределению предельных объемов бюджетных ассигнований.
11. Интеграционное тестирование и отладка.
12. Документирование:
12.1. Технический проект:
12.1.1. Пояснительная записка к техническому проекту системы.
12.1.2. Описание архитектуры системы.
12.2. Рабочая документация:
12.2.1. Общее описание системы.
12.2.2. Руководство пользователя системы.
12.2.3. Руководство администратора системы.
12.2.4. Программа и методика предварительных испытаний системы.
12.2.5. Программа опытной эксплуатации системы.
12.2.6. Акт ввода системы в опытную эксплуатацию (проект).
12.2.7. Ведомость машинных носителей информации.
13. Пуско-наладочные работы.
14. Предварительные испытания.
Длительность третьего этапа составляет 49 рабочих дней. В работе над проектом в рамках данного этапа, по аналогии с предшествующим, помимо руководителей задействованы все участники проектной команды: главные аналитики, аналитики, технические писатели, разработчики, тестеры и др.
Четвертый этап «Опытная эксплуатация и приемка системы» является завершающим и содержит подзадачи:
1. Обучение и консультация персонала системы по новым компонентам:
1.1. Техническое и сервисное сопровождение новых компонент системы.
1.2. Проведение оптимизации подсистем.
1.3. Анализ и устранение ошибок, выявленных в ходе опытной эксплуатации.
2. Документирование:
2.1. План-программа подготовки персонала.
2.2. Отчет о подготовке персонала.
2.3. Акт о проведении подготовки персонала.
2.4. Журнал проведения опытной эксплуатации.
2.5. Акт о завершении опытной эксплуатации.
2.6. Программа и методика комплексных приемочных испытаний.
2.7. Акт о готовности системы к промышленной эксплуатации.
3. Комплексные приемочные испытания.
4. Проектный офис:
4.1. Общее управление проектом.
4.2. Координация проектной команды.
4.3. Администрирование проекта.
Длительность четвертого, завершающего этапа составляет 71 рабочих день. В работе над проектом в рамках данного этапа помимо руководителей задействованы: главные аналитики, аналитики, технические писатели, разработчики, тестеры.
Общие затраты на реализацию разработки системы составляют 148 рабочих дней.
2.8 Моделирование процесса разработки информационной системы
С помощью специализированного инструмента моделирования бизнес-процессов ARIS, поддерживающего одноименную методологию описания бизнес-процессов, было построено несколько диаграмм разных уровней, описывающих процесс разработки информационной системы «Автоматизированная система управления городскими финансами» в качестве результата исполнения бизнес-процесса (см. Таблица 5).
Таблица 5. Перечень диаграмм, описывающих процесс разработки
|
Наименование диаграммы |
Описание |
Приложение |
|
|
Диаграмма цепочки добавленного качества |
1 Уровень: иллюстрирует всю деятельность Исполнителя на самом верхнем уровне. |
Приложение С |
|
|
2 Уровень: показывает процесс разработки и связанные с ним напрямую бизнес-процессы такие как контроль качества или обучение персонала функционального Заказчика. |
Приложение D |
||
|
Событийная цепочка процесса |
Детально представляет бизнес-процесс разработки: иллюстрирует взаимодействие клиента на разных этапах выполнения, предоставляет информацию о документации, формирующейся в процессе разработки решения. |
Приложение E |
|
|
Диаграмма окружения процесса |
Показывает окружение бизнес-процесса: участвующие в процессе нормативные документы, участвующие подразделения |
Приложение F |
2.9 Расчет оценки стоимости разработки информационной системы
В качестве основы расчета оценки стоимости разработки информационной системы была выбрана модель - COCOMO II. Согласно описываемой модели расчёты должны осуществляться следующим образом:
(17)
где
а - комплексный коэффициент, полученный путем обработки информации по большому количеству проектов разработки программного обеспечения за длительный промежуток времени (в рамках исследования коэффициент а = 2,94).
Size - сумма строк кода, представленная в тыс. строк (KSLOC).
EMi - множители трудоемкости разработки.
(18)
где
B - коэффициент зависимости трудозатрат от степени масштабируемости проекта, полученный путем обработки информации по большому количеству проектов за длительный промежуток времени.
SF - факторы, отражающих особенности проекта и коллектива разработчиков.
Так как в основе расчёта стоимости разработки лежит трудоемкость, требуется в первую очередь оценить соответствующие затраты труда, рабочего времени на создание и внедрение системы.
Входными параметрами для расчета трудоемкости являются:
· количество строк кода, подсчитанное исходя из оценки User Function Types (логических групп данных, которые используются и поддерживаются системой, и функциональности совершаемых транзакций);
· интегральная оценка масштабируемости проекта;
· интегральные множители трудоемкости.
Вычисление 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 |
Ненормированное количество функциональных точек (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 = 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 |
В итоге значение показателя масштабируемости составляет:
0,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 |
Зарплата основных специалистов (ФОТ) (Мосгорстат, январь-май 2016) |
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 (количество рабочих дней в 2016 году).
Среднемесячная заработная плата работников за январь-май 2016 года по полному кругу организаций, на основе данных Мосгорстата по виду деятельности «Разработка программного обеспечения и консультирование в этой области» составляет в среднем 58 052,90 руб.
Расчет суммарного размера тарифов страховых взносов в 2016 году, представленный в табличном формате - Таблица 10.
Таблица 10. Страховые взносы в ПФ, ФМС, ФСС
|
№ |
Наименования тарифов страховых взносов |
Ставка на 2016 год, % |
|
|
1 |
Тариф страховых взносов, уплачиваемых в Пенсионный фонд РФ |
22,0% |
|
|
2 |
Тариф страховых взносов, уплачиваемые в Фонд социального страхования РФ |
2,9% |
|
|
3 |
Тарифы страховых взносов, уплачиваемые в Федеральный фонд обязательного медицинского страхования |
3,1% |
|
|
4 |
Тарифы страховых взносов, уплачиваемые в территориальные фонды обязательного медицинского страхования |
2,0% |
|
|
5 |
Страховой тариф на обязательное социальное страхование от несчастных случаев на производстве и профессиональных заболеваний по I классу профессионального риска |
0,2% |
|
|
6 |
ИТОГО суммарный размер тарифов страховых взносов в 2016 г. |
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 Расчет ставки дисконтирования
При нахождении ставки дисконтирования нужно учитывать все факторы, которые могли бы изменить настоящую выгоду, которую можно получить от проекта. Суть дисконтирования заключается в том, что текущая стоимость будущих финансовых потоков может существенно отличаться от их номинальной стоимости. Согласно теории стоимости денег, одна и та же сумма, выплачиваемая в разные моменты времени, имеет разную стоимость.
Используя данные об уровне инфляции по состоянию на 2016 год, а также значение номинальной ставки дисконтирования, рассчитанной ранее, получаем значение реальной ставки дисконтирования:
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 тыс. руб. за весь период реализации проекта. Такое значение показателя является удовлетворительным и соответствует положительной динамике поступления доходов от реализации проекта.
Заключение
В данной работе приведено описание бизнес-архитектуры, проведено анализ экономической и технической рациональности реализации информационной системы «Автоматизированная система управления городскими финансами», составлен специальный документ - технико-экономическое обоснование. Представлено максимально детальное описание планируемых к реализации функциональных возможностей системы.
Разработаны компоненты бизнес-архитектуры такие как организационный, технологический, производственный планы. Проведена оценка стоимости разработки системы, а также рассчитаны экономические показатели эффективности.
Основной экономический эффект будет состоять в повышении производительности труда органов исполнительной власти, в т.ч. оперативное взаимодействие территориально удаленных структурных подразделений. Мероприятия по разработке и внедрению АСУ ГФ носят системообразующий характер для повышения эффективности использования информационных и коммуникационных технологий в деятельности функциональных заказчиков, и результативности расходования бюджетных средств, выделяемых на эти цели. Новое качество управления как результат реализации мероприятий является важным фактором социально-экономического развития и повышения качества жизни населения. С учётом заявленных целей представляется возможным оценить эффект реализации мероприятий по следующим основным направлениям:
· повышение эффективности деятельности органов исполнительной власти и государственных учреждений;
· обеспечение открытости и прозрачности деятельности органов исполнительной власти и государственных учреждений;
· повышение оперативности и качества принимаемых решений, сокращение издержек на управление за счёт создания единого информационного пространства.
Библиографический список
1. Zachman J. A Framework for Information Systems Architecture // IBM Systems Journal. 1987. Vol 16, pp 276 - 292.
2. Обзор архитектуры Microsoft // Microsoft Developer Network [Электронный ресурс] [Режим доступа: https://msdn.microsoft.com/ru-ru/library/ee872883.aspx] [Проверено: 27.04.2016].
3. Всяких Е., Сидоренко Е., Зуева А., Носков Б., Киселёв С. Практика и проблематика моделирования бизнес-процессов. М: ДМК Пресс, 2008.
4. Barry Boehm. Software engineering economics. Englewood Cliffs, NJ:Prentice-Hall, 1981. ISBN 0-13-822122-7
5. 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.
7. Дамодаран А. Инвестиционная оценка. - 2-е изд. - М.: Альпина Бизнес Букс, 2004.
8. Типовые организационные структуры предприятий // Корпоративный менеджмент [Электронный ресурс] [Режим доступа: http://www.cfin.ru/management/iso9000/iso9000_orgchart.shtml] [Проверено: 27.04.2016].
Приложение A. Модель, иллюстрирующая принцип организации проектной команды
Рисунок 1. Матричная организационная структура
Приложение B. Производственный план проекта
Таблица 12. Производственный план реализации разработки АСУГФ
|
Наименование задачи |
Сроки |
|||
|
Начало |
Окончание |
Длительность, рабочих дней |
||
|
Выполнение работ по разработке и развитию АСУ ГФ |
26.05.2016 |
22.12.2016 |
148 |
|
|
Этап 1. Обследование объекта автоматизации и уточнение требований к системе |
26.05.2016 |
15.07.2016 |
35 |
|
|
Обследование и уточнение требований |
27.05.2016 |
01.07.2016 |
25 |
|
|
Уточнение требований к подсистеме "Планирование и анализ доходной части бюджета" |
27.05.2016 |
01.07.2016 |
25 |
|
|
Уточнение требований к механизмам электронного документооборота в подсистеме "Планирование и анализ доходной части бюджета" (п. 4.2.1.1.1 ТЗ) |
27.05.2016 |
09.06.2016 |
10 |
|
|
Анализ и уточнение требований к аналитическим срезам модуля "Исполнения" (п. 4.2.2.3.1 ТЗ) |
27.05.2016 |
17.06.2016 |
15 |
|
|
Анализ и уточнение требований к модернизации механизмов журналирования и аудита с использованием МЦУП (п. 4.2.2.3.2 ТЗ) |
27.06.2016 |
01.07.2016 |
5 |
|
|
Уточнение требований к подсистеме АРМ руководителя ДФ Москвы |
27.05.2016 |
24.06.2016 |
20 |
|
|
Интервью заказчика и уточнение требований к веб-приложению (п. 4.2.2.4.1 ТЗ) |
27.05.2016 |
09.06.2016 |
10 |
|
|
Интервью заказчика и уточнение требований к мобильному приложению (п. 4.2.2.4.2 ТЗ) |
10.06.2016 |
24.06.2016 |
10 |
|
|
Уточнение требований к подсистеме Аналитической обработки данных |
27.05.2016 |
24.06.2016 |
20 |
|
|
Уточнение реквизитного состава паспортов открытых данных (п. 4.2.2.5.1 ТЗ) |
03.06.2016 |
17.06.2016 |
10 |
|
|
Анализ и уточнение требований к формату и составу передаваемых данных (п. 4.2.2.5.1 ТЗ) |
20.06.2016 |
24.06.2016 |
5 |
|
|
Интервью заказчика и уточнение перечня и требований к составу аналитических отчетов по расходам, доходам и государственным заданиям, на основе информации, передаваемой из подсистем АСУ ГФ и АИС УБП 1-М (п. 4.2.2.5.2 ТЗ) |
27.05.2016 |
17.06.2016 |
15 |
|
|
Анализ и уточнение требований к информационному взаимодействию с ГИИС "Открытый бюджет" (п. 4.2.2.7 ТЗ) |
27.05.2016 |
09.06.2016 |
10 |
|
|
Анализ и детализация требований к подсистеме Формирования и ведения бюджетных смет подведомственной сети учреждений (п. 4.2.2.8 ТЗ) |
27.05.2016 |
17.06.2016 |
15 |
|
|
Интервью заказчика и уточнение требований к аналитическим отчетным формам модуля ведения ведомственных перечней на основе федеральных отраслевых перечней (п. 4.2.2.9 ТЗ) |
10.06.2016 |
17.06.2016 |
5 |
|
|
Анализ и детализация требований подсистеме формирования госзаданий и соглашений на их фин.обеспечение (п. 4.2.2.10 ТЗ) |
27.05.2016 |
17.06.2016 |
15 |
|
|
Анализ и уточнение требований к дополнительным контрольным соотношениям подсистемы СШК (п. 4.2.2.7 ТЗ) |
27.05.2016 |
02.06.2016 |
5 |
|
|
Анализ и уточнение требований к информационному взаимодействию с УАИС "Бюджетный учет" (п. 4.2.2.20 ТЗ) |
27.05.2016 |
17.06.2016 |
15 |
|
|
Анализ и уточнение требований к подсистеме обеспечения юридической значимости (4.2.2.21 ТЗ) |
27.06.2016 |
01.07.2016 |
5 |
|
|
Обеспечение информационной безопасности |
27.05.2016 |
01.07.2016 |
25 |
|
|
Анализ обрабатываемых документов и классификация ИС |
27.05.2016 |
09.06.2016 |
10 |
|
|
Анализ угроз и описание потенциальных угроз и действий нарушителя ИБ ИС |
10.06.2016 |
24.06.2016 |
10 |
|
|
Анализ и формирование требований по обеспечению ИБ ИС |
27.06.2016 |
01.07.2016 |
5 |
|
|
Документирование |
04.07.2016 |
15.07.2016 |
10 |
|
|
Оформление и согласование отчета об обследовании |
04.07.2016 |
13.07.2016 |
8 |
|
|
Описание бизнес-сценариев автоматизируемых процессов (п. 8.1 ТЗ) |
04.07.2016 |
13.07.2016 |
8 |
|
|
Оформление и согласование ЧТЗ |
07.07.2016 |
15.07.2016 |
7 |
|
|
Этап 2. Техно-рабочий проект Системы в рамках реализации функций первой части |
16.07.2016 |
13.09.2016 |
42 |
|
|
Системное проектирование |
18.07.2016 |
11.08.2016 |
19 |
|
|
Анализ требований и проектирование архитектурных решений |
18.07.2016 |
22.07.2016 |
5 |
|
|
Анализ требований и проектирование хранилища данных |
29.07.2016 |
11.08.2016 |
10 |
|
|
Анализ требований и проектирование межкомпонентных интерфейсов |
29.07.2016 |
11.08.2016 |
10 |
|
|
Внедрение юридически значимого электронного документооборота (п. 4.2.1.1 ТЗ) |
25.07.2016 |
29.08.2016 |
26 |
|
|
Анализ текущей архитектуры и выработка решению по механизму юридической значимости |
25.07.2016 |
28.07.2016 |
4 |
|
|
Разработка спецификаций вызова модулей обеспечения юридической значимости |
05.08.2016 |
09.08.2016 |
3 |
|
|
Интеграционное тестирование и устранение ошибок |
26.08.2016 |
29.08.2016 |
2 |
|
|
Обеспечение возможности применения кодов бюджетной классификации в соответствии с принципами, установленными Федеральным законом от 22.10.2014 № 311-ФЗ (п. 4.2.1.2 ТЗ) |
18.07.2016 |
26.08.2016 |
30 |
|
|
Анализ текущей архитектуры и выработка решений по реализации изменений классификации бюджета |
18.07.2016 |
20.07.2016 |
3 |
|
|
Разработка пакета спецификаций на реализацию требований по изменению бюджетной классификации |
21.07.2016 |
22.07.2016 |
2 |
|
|
Модернизация экранных и отчетных форм системы |
25.07.2016 |
05.08.2016 |
10 |
|
|
Модернизация механизмов межсистемного взаимодействия |
25.07.2016 |
19.08.2016 |
20 |
|
|
Интеграционное тестирование межсистемного взаимодействия |
01.08.2016 |
26.08.2016 |
20 |
|
|
Развитие подсистемы планирования и анализа доходной части бюджета города Москвы (п. 4.2.2.3 ТЗ) |
29.07.2016 |
25.08.2016 |
20 |
|
|
Разработка спецификации на реализацию требований |
29.07.2016 |
04.08.2016 |
5 |
|
|
Модернизация программного обеспечения подсистемы |
05.08.2016 |
18.08.2016 |
10 |
|
|
Модульное тестирование и устранение ошибок |
19.08.2016 |
25.08.2016 |
5 |
|
|
Развитие подсистемы аналитической обработки данных (п. 4.2.2.5 ТЗ) |
18.07.2016 |
12.08.2016 |
20 |
|
|
Разработка спецификации по реализации требований |
18.07.2016 |
29.07.2016 |
10 |
|
|
Модернизация программного обеспечения подсистемы |
01.08.2016 |
05.08.2016 |
5 |
|
|
Модульное тестирование и устранение ошибок |
08.08.2016 |
12.08.2016 |
5 |
|
|
Создание модуля согласования и утверждения ведомственных перечней, сформированных на основании федеральных базовых (отраслевых) перечней (п. 4.2.2.9 ТЗ) |
25.07.2016 |
02.08.2016 |
7 |
|
|
Разработка спецификации на реализацию требований |
25.07.2016 |
27.07.2016 |
3 |
|
|
Разработка программного обеспечения модуля |
28.07.2016 |
29.07.2016 |
2 |
|
|
Модульное тестирование и устранение ошибок |
01.08.2016 |
02.08.2016 |
2 |
|
|
Развитие подсистемы Реестр расходных обязательств города Москвы (п. 4.2.2.12 ТЗ) |
18.07.2016 |
12.08.2016 |
20 |
|
|
Разработка спецификации на реализацию требований |
18.07.2016 |
22.07.2016 |
5 |
|
|
Модернизация программного обеспечения подсистемы |
25.07.2016 |
05.08.2016 |
10 |
|
|
Модульное тестирование и устранение ошибок |
08.08.2016 |
12.08.2016 |
5 |
|
|
Создание модуля обеспечения информационного взаимодействия с Фондом капитального ремонта города Москвы (п. 4.2.2.16 ТЗ) |
25.07.2016 |
26.08.2016 |
25 |
|
|
Разработка спецификации на реализацию требований |
25.07.2016 |
29.07.2016 |
5 |
|
|
Разработка программного обеспечения модуля |
01.08.2016 |
19.08.2016 |
15 |
|
|
Модульное тестирование и устранение ошибок |
22.08.2016 |
26.08.2016 |
5 |
|
|
Создание подсистемы «Обеспечения юридической значимости» (п. 4.2.2.21 ТЗ) |
29.07.2016 |
25.08.2016 |
20 |
|
|
Разработка спецификации на реализацию требований |
29.07.2016 |
04.08.2016 |
5 |
|
|
Разработка программного обеспечения подсистемы |
05.08.2016 |
18.08.2016 |
10 |
|
|
Модульное тестирование и устранение ошибок |
19.08.2016 |
25.08.2016 |
5 |
|
|
Интеграционное тестирование и отладка |
30.08.2016 |
05.09.2016 |
5 |
|
|
Документирование |
12.08.2016 |
06.09.2016 |
18 |
|
|
Технический проект |
12.08.2016 |
25.08.2016 |
10 |
|
|
Пояснительная записка к техническому проекту Системы |
12.08.2016 |
25.08.2016 |
10 |
|
|
Описание архитектуры Системы |
12.08.2016 |
25.08.2016 |
10 |
|
|
Рабочая документация |
23.08.2016 |
05.09.2016 |
10 |
|
|
Общее описание Системы |
26.08.2016 |
01.09.2016 |
5 |
|
|
Руководство пользователя Системы |
23.08.2016 |
05.09.2016 |
10 |
|
|
Руководство администратора Системы |
30.08.2016 |
05.09.2016 |
5 |
|
|
Программа и методика предварительных испытаний Системы |
01.09.2016 |
05.09.2016 |
3 |
|
|
Программа опытной эксплуатации Системы |
01.09.2016 |
05.09.2016 |
3 |
|
|
Акт ввода Системы в опытную эксплуатацию (проект) |
01.09.2016 |
05.09.2016 |
3 |
|
|
Ведомость машинных носителей информации |
06.09.2016 |
06.09.2016 |
1 |
|
|
Пуско-наладочные работы |
06.09.2016 |
06.09.2016 |
1 |
|
|
Предварительные испытания |
07.09.2016 |
13.09.2016 |
5 |
|
|
Этап 3. Техно-рабочий проект Системы в рамках реализации функций второй части |
14.09.2016 |
22.11.2016 |
49 |
|
|
Системное проектирование |
14.09.2016 |
25.10.2016 |
30 |
|
|
Анализ требований и проектирование архитектурных решений |
14.09.2016 |
20.09.2016 |
5 |
|
|
Анализ требований и проектирование хранилища данных |
12.10.2016 |
25.10.2016 |
10 |
|
|
Анализ требований и проектирование межкомпонентных интерфейсов |
12.10.2016 |
25.10.2016 |
10 |
|
|
Развитие подсистемы планирования расходной части бюджета города Москвы (п. 4.2.2.2 ТЗ) |
21.09.2016 |
01.11.2016 |
30 |
|
|
Разработка спецификации на реализацию требований |
21.09.2016 |
04.10.2016 |
10 |
|
|
Модернизация программного обеспечения подсистемы |
05.10.2016 |
25.10.2016 |
15 |
|
|
Модульное тестирование и устранение ошибок |
26.10.2016 |
01.11.2016 |
5 |
|
|
Развитие автоматизированного рабочего места руководителя Департамента финансов города Москвы (п. 4.2.2.4 ТЗ) |
14.09.2016 |
13.10.2016 |
22 |
|
|
Разработка спецификации на модернизацию "обычной" версии |
14.09.2016 |
20.09.2016 |
5 |
|
|
Модернизация программного обеспечения "обычной" версии |
21.09.2016 |
04.10.2016 |
10 |
|
|
Модульное тестирование и устранение ошибок "обычной" версии |
05.10.2016 |
11.10.2016 |
5 |
|
|
Разработка спецификации на модернизацию мобильной версии |
21.09.2016 |
04.10.2016 |
10 |
|
|
Модернизация программного обеспечения мобильной версии |
05.10.2016 |
10.10.2016 |
4 |
|
|
Модульное тестирование АРМ руководителя и устранение ошибок |
12.10.2016 |
13.10.2016 |
2 |
|
|
Создание подсистемы формирования и ведения бюджетных смет по подведомственной сети учреждений (п. 4.2.2.8 ТЗ) |
21.09.2016 |
01.11.2016 |
30 |
|
|
Разработка спецификации на создание подсистемы |
21.09.2016 |
04.10.2016 |
10 |
|
|
Создание программного обеспечения подсистемы |
05.10.2016 |
25.10.2016 |
15 |
|
|
Модульное тестирование и устранение ошибок |
26.10.2016 |
01.11.2016 |
5 |
|
|
Развитие подсистемы ведения государственных заданий (п. 4.2.2.10 ТЗ) |
14.09.2016 |
25.10.2016 |
30 |
|
|
Разработка спецификации на модернизацию подсистемы |
14.09.2016 |
27.09.2016 |
10 |
|
|
Модернизация программного обеспечения подсистемы |
28.09.2016 |
18.10.2016 |
15 |
|
|
Модульное тестирование и устранение ошибок |
19.10.2016 |
25.10.2016 |
5 |
|
|
Развитие подсистемы ведения реестра государственных, муниципальных учреждений (п. 4.2.2.11 ТЗ) |
14.09.2016 |
14.10.2016 |
23 |
|
|
Разработка спецификации на модернизацию подсистемы |
14.09.2016 |
20.09.2016 |
5 |
|
|
Модернизация программного обеспечения |
21.09.2016 |
04.10.2016 |
10 |
|
|
Модульное тестирование и устранение ошибок |
05.10.2016 |
11.10.2016 |
5 |
|
|
Интеграционное тестирование АСИ УБП-1М и устранение ошибок |
12.10.2016 |
14.10.2016 |
3 |
|
|
Развитие подсистемы «Сводная бюджетная роспись» (п. 4.2.2.18 ТЗ) |
21.09.2016 |
18.10.2016 |
20 |
|
|
Разработка спецификации на модернизацию подсистемы |
21.09.2016 |
27.09.2016 |
5 |
|
|
Модернизация программного обеспечения подсистемы |
28.09.2016 |
11.10.2016 |
10 |
|
|
Модульное тестирование и устранение ошибок |
12.10.2016 |
18.10.2016 |
5 |
|
|
Документирование |
26.10.2016 |
15.11.2016 |
14 |
|
|
Технический проект |
26.10.2016 |
01.11.2016 |
5 |
|
|
Пояснительная записка к техническому проекту Системы |
26.10.2016 |
01.11.2016 |
5 |
|
|
Описание архитектуры Системы |
26.10.2016 |
01.11.2016 |
5 |
|
|
Рабочая документация |
26.10.2016 |
15.11.2016 |
14 |
|
|
Общее описание Системы |
26.10.2016 |
01.11.2016 |
5 |
|
|
Руководство пользователя Системы |
02.11.2016 |
14.11.2016 |
8 |
|
|
Руководство администратора Системы |
10.11.2016 |
15.11.2016 |
4 |
|
|
Программа и методика предварительных испытаний Системы |
10.11.2016 |
14.11.2016 |
3 |
|
|
Программа опытной эксплуатации Системы |
14.11.2016 |
15.11.2016 |
2 |
|
|
Акт ввода Системы в опытную эксплуатацию (проект) |
14.11.2016 |
15.11.2016 |
2 |
|
|
Ведомость машинных носителей информации |
14.11.2016 |
14.11.2016 |
1 |
|
|
Пуско-наладочные работы |
14.11.2016 |
14.11.2016 |
1 |
|
|
Предварительные испытания |
16.11.2016 |
22.11.2016 |
5 |
|
|
Этап 4. Опытная эксплуатация и приемка Системы |
14.09.2016 |
22.12.2016 |
71 |
|
|
Обучение и консультация персонала Системы по новым компонентам |
14.09.2016 |
15.12.2016 |
66 |
|
|
Техническое и сервисное сопровождение новых компонент Системы |
14.09.2016 |
15.12.2016 |
66 |
|
|
Проведение SEO оптимизации портала "Открытый бюджет" |
14.09.2016 |
15.12.2016 |
66 |
|
|
Анализ и устранение ошибок, выявленных в ходе опытной эксплуатации |
14.09.2016 |
15.12.2016 |
66 |
|
|
Документирование |
14.09.2016 |
15.12.2016 |
66 |
|
|
План-программа подготовки персонала |
14.09.2016 |
20.09.2016 |
5 |
|
|
Отчет о подготовке персонала |
09.12.2016 |
15.12.2016 |
5 |
|
|
Акт о проведении подготовки персонала |
09.12.2016 |
15.12.2016 |
5 |
|
|
Журнал проведения опытной эксплуатации |
14.09.2016 |
15.12.2016 |
66 |
|
|
Акт о завершении опытной эксплуатации |
09.12.2016 |
15.12.2016 |
5 |
|
|
Программа и методика комплексных приемочных испытаний |
13.12.2016 |
15.12.2016 |
3 |
|
|
Акт о готовности системы к промышленной эксплуатации |
13.12.2016 |
15.12.2016 |
3 |
|
|
Комплексные приемочные испытания |
16.12.2016 |
22.12.2016 |
5 |
|
|
Проектный офис |
27.05.2016 |
22.12.2016 |
148 |
|
|
Общее управление проектом |
27.05.2016 |
22.12.2016 |
148 |
|
|
Координация проектной команды |
27.05.2016 |
22.12.2016 |
148 |
|
|
Администрирование проекта |
27.05.2016 |
22.12.2016 |
148 |
|
|
ИТОГО: |
27.05.2016 |
22.12.2016 |
148 |
|
|
27.05.2016 |
22.12.2016 |
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
Размещено на Allbest.ru
Подобные документы
Подходы к описанию бизнес-архитектуры и стандарты составления технико-экономического обоснования. Назначение, цели и стоимость разработки информационной системы (ИС), описание её функциональных возможностей. Моделирование процесса разработки ИС.
дипломная работа [1,3 M], добавлен 18.02.2017Описание предпроектной (разработка технико-экономического обоснования) и проектной (создание технического и рабочего проекта) стадий разработки автоматической системы управления, ввод ее в эксплуатацию путем проведения монтажных и пусконаладочных работ.
реферат [28,0 K], добавлен 25.10.2010Функциональная структура информационной системы предприятия, достоинства, недостатки, перспективы ее развития. Типы ИС с учетом уровней управления и квалификации персонала. Требования к автоматизированной системе, сущность подсистемы управления финансами.
контрольная работа [740,2 K], добавлен 25.07.2010Специфика управления финансами предприятий и холдингов. Программный продукт "1С:Предприятие 8.Управление корпоративными финансами" - интегрированное решение на базе программ "1С:Бухгалтерия 8" и сконфигурированных функционально расширенных подсистем.
контрольная работа [404,4 K], добавлен 12.01.2012Трудность создания, внедрения и эксплуатации автоматизированной системы документационного обеспечения управления. Защита информации в электронном документообороте. Автоматизированная система LanDocs. Основные функции системы. Принципы защиты информации.
реферат [31,1 K], добавлен 11.12.2009Способ реализации автоматизированной системы расчета маршрута для курьерской компании. Особенности архитектуры ОС Android. Обзор и решение ключевых задач. Прогнозирование времени прохождения маршрута, диспетчеризация. Графический интерфейс системы.
дипломная работа [4,8 M], добавлен 22.06.2012Разработка архитектуры ключевых прикладных систем предприятия. Разработка требований к системе управления качеством и контроллинга бизнес-процесса. Анализ разрывов между исходным и целевым состоянием бизнес-процесса. Разработка диаграммы миграции.
курсовая работа [6,3 M], добавлен 12.03.2022Цель создания информационной системы. Автоматизированная информационная система "Строительное предприятие". Использование вычислительной техники и программного обеспечения для создания автоматизированной информационной системы управления на предприятии.
курсовая работа [2,5 M], добавлен 04.01.2011Описание системы автономного водоснабжения административного здания морского терминала ЗАО "Каспийский Трубопроводный Консорциум". Разработка и программная реализация алгоритма управления системой. Анализ и нормирование вредных производственных факторов.
дипломная работа [2,9 M], добавлен 14.11.2010Проектирование подсистем реализации автомобиля, ввода и редактирования информации, составления отчётов и подсистемы администрирования. Требования к системе. Использование CASE средства AllFusion Process Modeler BPWin для создания моделей бизнес-процессов.
дипломная работа [2,4 M], добавлен 29.06.2012
