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

Как написать ВКР МУИВ на тему Разработка автоматизированной информационной системы для управления портфелем инвестиций предприятия

Нужна ВКР по этой теме? Ответим за 10 минут!
Telegram: @Diplomit
Телефон/WhatsApp: +7 (987) 915-99-32, Email: admin@diplom-it.ru

Оформите заказ онлайн: Заказать ВКР МУИВ

Написание выпускной квалификационной работы (ВКР) в Московском университете имени С.Ю. Витте (МУИВ) по направлению подготовки 09.03.02 «Информационные системы и технологии» — финальный, но крайне ответственный этап, требующий системного подхода к решению сложных финансово-аналитических задач. Тема «Разработка автоматизированной информационной системы для управления портфелем инвестиций предприятия» особенно актуальна в условиях высокой волатильности рынков и роста требований к прозрачности и обоснованности инвестиционных решений. В большинстве предприятий, включая условную компанию ООО «ИнвестГрупп», управление инвестиционным портфелем осуществляется вручную с использованием Excel-файлов и разрозненных источников данных (биржевые терминалы, отчёты аналитиков, внутренние отчёты). Такой подход не позволяет оперативно оценивать риски, рассчитывать ключевые показатели эффективности (IRR, NPV, ROI) в реальном времени и строить сценарный анализ, что приводит к принятию субъективных решений и потенциальным финансовым потерям.

Стандартная структура ВКР МУИВ требует не просто написать код для расчёта IRR, а продемонстрировать полный цикл создания сложной аналитической системы: от анализа существующих методик управления портфелем и моделирования бизнес-процессов до проектирования архитектуры с интеграцией финансовых API, реализации модулей анализа и визуализации, и всестороннего экономического обоснования. Это комплексный проект, объёмом в 150–200 часов, сочетающий в себе глубокие знания финансового анализа, ИТ-архитектуры и экономики. Эта статья — ваше подробное, пошаговое руководство по написанию такой ВКР. В ней вы найдёте конкретные инструкции и примеры для каждого раздела, что поможет вам принять взвешенное решение.

Нужна ВКР по этой теме? Ответим за 10 минут!
Telegram: @Diplomit
Телефон/WhatsApp: +7 (987) 915-99-32, Email: admin@diplom-it.ru

Оформите заказ онлайн: Заказать ВКР МУИВ

ВВЕДЕНИЕ

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

Содержание:

• Актуальность темы в современных условиях: В условиях рыночной нестабильности эффективное управление инвестиционным портфелем становится критическим фактором финансовой устойчивости предприятия. В ООО «ИнвестГрупп» учёт и анализ инвестиционных проектов ведётся в Excel-файлах, что не позволяет в реальном времени оценивать риск-доходность, проводить стресс-тестирование или рассчитывать агрегированные показатели портфеля (общий NPV, волатильность). Это приводит к принятию решений на основе устаревших данных и увеличивает вероятность финансовых потерь на 15-20% по оценкам финансового департамента.
• Объект и предмет исследования: Объектом исследования выступает финансовая деятельность ООО «ИнвестГрупп». Предметом исследования является процесс анализа, отбора, мониторинга и управления инвестиционными проектами в портфеле предприятия.
• Цель и задачи работы (4-6 конкретных задач):
  1. Провести анализ существующих методик и инструментов управления инвестиционным портфелем (модель Марковица, CAPM, методы оценки).
  2. Изучить текущий процесс управления портфелем в ООО «ИнвестГрупп» и выявить ключевые недостатки (ручной учёт, отсутствие аналитики, фрагментация данных).
  3. Разработать архитектуру автоматизированной информационной системы (АИС) для управления портфелем.
  4. Спроектировать и реализовать АИС с модулями: каталог проектов, расчёт показателей (NPV, IRR, ROI), риск-анализ, сценарное моделирование, дашборд.
  5. Обеспечить интеграцию системы с внешними финансовыми API (например, для получения рыночных данных).
  6. Рассчитать экономическую эффективность от внедрения АИС.
• Структура работы (краткое описание глав): Работа состоит из введения, трёх основных глав (аналитической, проектной, экономической), заключения, списка литературы и приложений.

Частые ошибки и сложности: Расплывчатая актуальность без привязки к конкретной компании и финансовым показателям. Смешение задач по финансовому анализу и разработке ПО.

Практические рекомендации: Начните актуальность с цифры: «В ООО «ИнвестГрупп» из-за ручного управления портфелем потери от непринятых оптимальных решений оцениваются в 5 млн руб. в год...».

Примеры/шаблоны: «Актуальность работы обусловлена необходимостью автоматизации управления инвестиционным портфелем предприятия в условиях высокой рыночной волатильности и неэффективности ручных методов учёта и анализа, что приводит к финансовым потерям в ООО «ИнвестГрупп»...»

АНАЛИТИЧЕСКАЯ ЧАСТЬ

1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Анализ подразделения «Управление инвестициями» организации ООО «ИнвестГрупп»

1.1.1 Дерево бизнес-направлений организации

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

Содержание: Дерево бизнес-направлений строится как иерархическая схема, отражающая основные линии бизнеса и их подчинённость. Для ООО «ИнвестГрупп» такая схема выглядит следующим образом. На вершине иерархии находится Генеральный директор. Ему непосредственно подчиняются два ключевых блока: 1) Операционный блок (управление основной деятельностью компании) и 2) Финансовый блок, который включает Бухгалтерию, Казначейство и Департамент стратегического развития. В составе Департамента стратегического развития функционирует подразделение «Управление инвестициями», состоящее из Аналитиков по инвестициям, Менеджеров инвестиционных проектов и Руководителя подразделения. Именно это подразделение является основным исполнителем в исследуемом процессе анализа и управления инвестиционным портфелем.

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

Практические рекомендации: Используйте типовую, логически обоснованную структуру для компании, занимающейся управлением инвестициями, с 50-100 сотрудниками. Чётко укажите в пояснительном тексте, что структура является условной, но репрезентативной для данного сегмента бизнеса и соответствует общепринятым практикам в области корпоративного управления.

Примеры/шаблоны: [Здесь приведите схему: ООО «ИнвестГрупп» → Генеральный директор → Финансовый блок → Департамент стратегического развития → Подразделение «Управление инвестициями» (Аналитики, Менеджеры проектов, Руководитель)].

1.1.2 Сопоставление бизнес-процессов и критических факторов успеха организации

Назначение: Этот подраздел призван на научной основе доказать, что именно процесс управления инвестиционным портфелем является приоритетным направлением для автоматизации. Для этого используется методика CSF (Critical Success Factors — Критические факторы успеха).

Содержание: Работа строится в два этапа. На первом этапе необходимо определить ключевые критические факторы успеха (КФУ) для ООО «ИнвестГрупп». Для компании, чья деятельность напрямую связана с инвестициями, такими факторами являются: 1) Доходность инвестиционного портфеля, 2) Эффективное управление рисками, 3) Обоснованность и прозрачность инвестиционных решений, 4) Оперативность анализа и реагирования на рыночные изменения. На втором этапе составляется матрица, в которой по вертикали перечисляются ключевые бизнес-процессы, связанные с инвестициями: «Сбор и анализ данных по потенциальным проектам», «Оценка и отбор инвестиционных проектов», «Мониторинг и управление текущим портфелем», «Формирование отчётности и принятие стратегических решений». В ячейках матрицы проставляются оценки по 5-балльной шкале, насколько каждый процесс влияет на достижение каждого КФУ. Затем подсчитывается суммарный балл для каждого процесса. Процесс «Мониторинг и управление текущим портфелем» набирает наивысший балл (18 из 20), что делает его приоритетным для автоматизации.

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

Практические рекомендации: Чётко разделяйте понятия «процесс» и «функция». Процесс — это последовательность действий, создающая ценность для бизнеса (например, «от анализа проекта до его включения в портфель»). Используйте методику CSF строго по её канону, чтобы ваш анализ выглядел профессионально и убедительно.

Примеры/шаблоны:

Бизнес-процесс	Доходность	Управление рисками	Обоснованность решений	Оперативность	Сумма
Мониторинг и управление портфелем	5	5	4	4	18
Оценка и отбор проектов	4	4	5	3	16

1.1.3 Анализ структуры и нормативной документации подразделения

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

Содержание: В рамках этого подраздела следует описать организационную структуру непосредственно подразделения «Управление инвестициями», включая штатное расписание (Руководитель, 3 Аналитика, 2 Менеджера проектов). Далее необходимо проанализировать существующую нормативную базу: 1) Должностные инструкции для аналитиков, которые, как правило, содержат общие фразы вроде «обеспечивает качественный анализ инвестиционных проектов», но не регламентируют конкретные шаги и методики расчётов; 2) Регламент по оценке инвестиционных проектов, который, по оценкам, существует в виде неформального документа, описывающего методику расчёта NPV и IRR в Excel, но не включает современные подходы к оценке рисков; 3) Шаблоны внутренних отчётов для руководства, которые носят описательный характер и не содержат интерактивной аналитики или визуализации. Ключевой вывод должен быть следующим: существующая документация носит фрагментарный, несистемный и устаревший характер, не обеспечивает единообразия в работе и не позволяет эффективно контролировать процесс в условиях высокой рыночной волатильности.

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

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

1.2 Моделирование бизнес-процесса

1.2.1 Моделирование "КАК ЕСТЬ"

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

Содержание: Этот подраздел является одним из самых объёмных и важных в аналитической главе. Необходимо создать комплекс из четырёх взаимодополняющих моделей:

1. IDEF0 (функциональная модель): Начинаем с контекстной диаграммы (A0), которая показывает процесс «Управление инвестиционным портфелем» как чёрный ящик. Входами являются «Информация о потенциальных и текущих проектах», выходами — «Решение об инвестировании/диверсификации/ликвидации» и «Отчёты по портфелю». Механизмами выступают «Аналитики, Менеджеры», а управлением — «Внутренние регламенты и финансовая стратегия ООО «ИнвестГрупп»». Обязательна декомпозиция на диаграмму A1, которая должна содержать как минимум 4 функциональных блока: A1.1 «Сбор и агрегация данных по проектам», A1.2 «Расчёт финансовых показателей (NPV, IRR) в Excel», A1.3 «Анализ рисков и сценарное моделирование», A1.4 «Формирование отчёта и принятие решения».
2. DFD (диаграмма потоков данных): Эта модель показывает, как данные (финансовые потоки, рыночные котировки, отчёты) перемещаются между внешними сущностями (Биржевые терминалы, Аналитические агентства) и процессами («Сбор данных», «Расчёт показателей»), а также где эти данные хранятся (например, в «Excel-файлах аналитиков», «Базе данных казначейства»). Важно показать, что данные фрагментированы по разным хранилищам и не интегрированы в единую систему.
3. Диаграмма активностей (BPMN): Эта модель описывает последовательность действий конкретного аналитика. Например, утром он проверяет email на новые отчёты, затем открывает 3-4 Excel-файла, вручную копирует данные, запускает макросы для расчёта NPV, далее переключается в браузер для проверки актуальных ставок, и только потом приступает к анализу. На диаграмме должны быть отражены ворота (решения: «Данные актуальны?»), параллельные потоки и таймеры (ежедневный сбор информации).
4. Матрица распределения ответственности (RACI): Таблица, где по вертикали перечислены все действия процесса, а по горизонтали — роли (Аналитик, Менеджер проекта, Руководитель подразделения, Финансовый директор). В ячейках указано: Responsible (R — кто выполняет), Accountable (A — кто утверждает), Consulted (C — кого консультируют) и Informed (I — кого информируют).

Частые ошибки и сложности: Самые частые ошибки — это грубое нарушение синтаксиса нотаций. Например, в IDEF0 стрелки управления и входа путают местами, или в DFD процессы подключаются напрямую к другим процессам без потока данных. Критическая ошибка — отсутствие обязательной декомпозиции (A1) в IDEF0.

Практические рекомендации: Не допускайте, чтобы диаграмма существовала сама по себе. Каждую из них необходимо сопровождать подробным текстовым описанием, поясняющим её элементы и логику взаимодействия. Например: «На диаграмме IDEF0 функция A1.2 «Расчёт финансовых показателей» включает в себя ручной ввод данных в Excel-шаблон с формулами для NPV и IRR, что занимает до 2 часов на проект и подвержено ошибкам».

Примеры/шаблоны: [Ссылка на рисунок 1.2 — IDEF0 диаграмма «Управление инвестиционным портфелем (модель "КАК ЕСТЬ")»].

1.2.2 Моделирование процесса "КАК ДОЛЖНО БЫТЬ"

Назначение: Предложить и визуализировать целевую, оптимизированную модель бизнес-процесса, которая лишена выявленных в модели «КАК ЕСТЬ» недостатков.

Содержание: Работа в этом подразделе строится по следующему алгоритму:

1. Оценка проблемности процесса: Создаётся таблица, где для каждого выявленного недостатка (например, «Ручной расчёт NPV занимает 2 часа и подвержен ошибкам») указываются три критерия: частота возникновения (в баллах от 1 до 5), влияние на бизнес (от 1 до 5), трудоёмкость устранения (от 1 до 5). Общий балл проблемности рассчитывается как сумма произведений.
2. Формулировка целей и ключевых показателей эффективности (KPI): На основе оценки формулируются измеримые цели. Например: «Сократить время расчёта NPV/IRR для одного проекта с 2 часов до 5 минут», «Обеспечить автоматическое обновление рыночных данных в реальном времени», «Внедрить инструменты сценарного анализа и стресс-тестирования», «Повысить агрегированную доходность портфеля на 2% за счёт более обоснованных решений».
3. Создание оптимизированной модели: Строится новый комплекс диаграмм в тех же нотациях (IDEF0, DFD, BPMN, RACI), что и в модели «КАК ЕСТЬ». Ключевые изменения: все данные по проектам и рынку поступают в единую АИС, которая автоматически рассчитывает все показатели, строит графики и позволяет менеджеру запускать сценарный анализ. Отчёт формируется в один клик и доступен руководству в режиме реального времени.

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

Практические рекомендации: Используйте конкретные, признанные в индустрии методы оптимизации: 1) Централизация данных в единой АИС, 2) Автоматизация расчётов с использованием проверенных финансовых алгоритмов, 3) Интеграция с внешними API для получения актуальных рыночных данных, 4) Внедрение инструментов визуализации и сценарного моделирования.

Примеры/шаблоны: KPI примеры:

• Время расчёта NPV/IRR (цель: ≤ 5 минут)
• Актуальность рыночных данных (цель: обновление в реальном времени)
• Доходность инвестиционного портфеля (цель: +2% в год)
• Время формирования отчёта для руководства (цель: ≤ 1 минута)

1.3 Анализ рынка программного обеспечения для автоматизации бизнес-процесса

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

Содержание: Необходимо проанализировать от 3 до 5 систем-аналогов. Для каждой системы следует привести:

• Производителя:
• Основной функционал:
• Стоимость:
• Сильные и слабые стороны: Оценка в контексте конкретной задачи ООО «ИнвестГрупп» (управление портфелем среднего размера с фокусом на прямые инвестиции).

Примеры систем для анализа:

1. Bloomberg Terminal: Лидер рынка для профессиональных трейдеров и аналитиков. Сильные стороны: безупречные данные, мощнейший аналитический инструментарий. Слабые стороны: экстремально высокая стоимость (около 24 000 $ в год за лицензию), избыточность функционала для задач управления корпоративным портфелем, ориентированность на торги, а не на стратегическое управление.
2. SAP Financial Supply Chain Management (FSCM): Модуль крупной ERP-системы. Сильные стороны: глубокая интеграция с другими модулями SAP (бухгалтерия, логистика). Слабые стороны: очень высокая стоимость внедрения и лицензирования, сложность настройки, фокус на управлении денежными потоками, а не на оценке инвестиционных проектов.
3. Addepar: Специализированная платформа для семейных офисов и wealth-менеджеров. Сильные стороны: отличная визуализация, агрегация данных. Слабые стороны: высокая стоимость (от 50 000 $ в год), ориентирована на управление портфелем ценных бумаг, а не на прямые инвестиции в проекты, что является ключевой деятельностью ООО «ИнвестГрупп».
4. eFront: Платформа для альтернативных инвестиций (private equity, venture capital). Сильные стороны: подходит для прямых инвестиций. Слабые стороны: очень высокая стоимость (от 100 000 $ в год), сложность и длительность внедрения (6+ месяцев), избыточность для компании среднего размера.

Частые ошибки и сложности: Главная и самая грубая ошибка — путаница между готовыми программными продуктами (CRM, ERP, специализированные платформы) и средствами разработки (языки программирования, фреймворки). Это абсолютно разные вещи, которые рассматриваются в разных разделах (1.3 и 1.5 соответственно).

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

Примеры/шаблоны:

Система	Производитель	Функционал для прямых инвестиций	Стоимость (год)	Подходит для ООО «ИнвестГрупп»?
Bloomberg Terminal	Bloomberg L.P.	Слабый	~1 800 000 руб.	Нет
eFront	SS&C Technologies	Отличный	~7 500 000 руб.	Избыточно/дорого
Собственная разработка	—	Полностью под ключ	150 000 руб. (единоразово)	Да

1.4 Анализ стейкхолдеров и их требований к разрабатываемой системе

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

Содержание: Список стейкхолдеров должен включать как внутренних, так и внешних участников:

• Внутренние стейкхолдеры:
  • Аналитики по инвестициям: Требуют автоматического расчёта NPV, IRR, ROI; инструментов для анализа чувствительности и сценарного моделирования; интеграции с источниками рыночных данных; возможности создавать и сохранять собственные аналитические шаблоны.
  • Менеджеры инвестиционных проектов: Требуют простого интерфейса для отслеживания KPI своих проектов, уведомлений о критических изменениях, инструментов для планирования денежных потоков.
  • Руководитель подразделения «Управление инвестициями»: Требует панели мониторинга с агрегированными показателями по всему портфелю (общий NPV, волатильность, распределение по секторам), инструментов для сравнения проектов и формирования сводных отчётов.
  • Финансовый директор: Требует стратегического дашборда с ключевыми финансовыми метриками (доходность портфеля, риск, ликвидность), возможностью проводить стресс-тестирование и моделировать влияние решений на финансовые показатели компании.
  • Генеральный директор: Интересуется общей картиной: эффективностью инвестиционной стратегии, балансом между риском и доходностью, долгосрочными перспективами.
• Внешние стейкхолдеры:
  • Аудиторы: Требуют прозрачности расчётов, возможности аудита всех операций и данных, соответствия отчётности стандартам.

Частые ошибки и сложности: Неполный охват заинтересованных сторон. Часто студенты забывают про руководство высшего звена как конечного потребителя стратегической аналитики или про аудиторов как внешних контролёров.

Практические рекомендации: Используйте матрицу заинтересованных сторон, где по осям X и Y отложены «Уровень влияния на проект» и «Уровень заинтересованности в результате». Это поможет вам расставить приоритеты при сборе и реализации требований, уделяя основное внимание группам с высоким влиянием и заинтересованностью (Аналитики, Финансовый директор).

1.5 Выбор средств разработки

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

Содержание: Работа в этом подразделе включает три ключевых этапа:

1. Анализ существующего ПО в организации: В ООО «ИнвестГрупп» используется 1С:Управление нашей фирмой для бухгалтерии и внутреннего учёта на Windows-серверах. Это накладывает определённые ограничения на выбор технологий для обеспечения совместимости и простоты интеграции.
2. Сравнительный анализ альтернатив: Для каждого компонента стека проводится сравнительный анализ.
   • Frontend: React vs Angular vs Vue.js. React выбран за его огромную экосистему библиотек для визуализации данных (D3.js, Chart.js), компонентную архитектуру и гибкость в построении сложных интерактивных дашбордов.
   • Backend: Python/Django vs Node.js/Express vs .NET Core. Python/Django выбран за богатую научную и финансовую экосистему (библиотеки NumPy, SciPy, pandas для расчётов, scikit-learn для анализа), а также за встроенную админку и высокий уровень безопасности «из коробки».
   • СУБД: PostgreSQL vs MySQL vs MS SQL Server. PostgreSQL выбран за его надёжность, поддержку сложных типов данных (массивы, JSONB для хранения сценариев), встроенные функции для работы с временными рядами и финансовыми расчётами, а также отличную производительность при сложных аналитических запросах.
3. Обоснование интеграций: Для получения рыночных данных будет использовано бесплатное API Alpha Vantage, которое предоставляет исторические котировки, данные о фундаментальных показателях и технические индикаторы. Это API выбрано за простоту интеграции и достаточность данных для целей ООО «ИнвестГрупп».

Частые ошибки и сложности: Основная ошибка — смешение этого раздела с разделом 1.3 (анализ готовых систем). Здесь речь идёт не о готовых продуктах, а о «кирпичиках» для строительства собственного решения.

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

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

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

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

• Введение (цель создания системы, основание для разработки).
• Назначение системы (цели, решаемые задачи: автоматизация расчёта NPV/IRR, управление портфелем, сценарный анализ).
• Требования к системе:
  • Требования к функциональным характеристикам (модули: Каталог проектов, Расчёт показателей, Риск-анализ, Сценарное моделирование, Дашборд).
  • Требования к надёжности (доступность 99.9%, резервное копирование).
  • Требования к интерфейсу (интуитивно понятный дашборд, визуализация данных).
  • Требования к информационной и программной совместимости (интеграция с 1С, Alpha Vantage API).
• Требования к документации.
• Стадии и этапы разработки.
• Порядок контроля и приёмки системы.

Полный текст технического задания выносится в Приложение 1 к ВКР.

Частые ошибки и сложности: Самая частая ошибка — несоблюдение структуры и формулировок, предписанных ГОСТом. Студенты часто пишут ТЗ в свободной форме, превращая его в список желаний, что является грубым нарушением требований.

Практические рекомендации: Используйте официальный текст ГОСТ 34.602-2020 как подробный чек-лист. Каждый его подраздел должен найти своё отражение в вашем документе. Это гарантирует, что ТЗ будет принято научным руководителем.

1.7 Выводы по разделу

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

Содержание: В этом подразделе необходимо кратко, но ёмко резюмировать выводы по каждому предыдущему пункту (1.1–1.6) и сделать общий, обобщающий вывод. Например: «По результатам анализа организационной структуры (п. 1.1) установлено, что в ООО «ИнвестГрупп» отсутствует единая система для управления инвестиционным портфелем. Моделирование текущего состояния "КАК ЕСТЬ" (п. 1.2.1) выявило критические проблемы: ручной трудоёмкий расчёт показателей, фрагментация данных и отсутствие инструментов для сценарного анализа. Анализ рынка готовых решений (п. 1.3) показал, что существующие системы либо слишком дороги (Bloomberg, eFront), либо не охватывают специфику прямых инвестиций. Таким образом, разработка собственной автоматизированной информационной системы является единственно верным и обоснованным решением для повышения эффективности инвестиционной деятельности ООО «ИнвестГрупп»».

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

Практические рекомендации: Начинайте каждый тезис с фразы «По результатам анализа (п. 1.X)...». Это создаёт чёткую логическую связь и показывает, что выводы делаются на основе проделанной работы, а не на пустом месте.

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

ПРОЕКТНАЯ ЧАСТЬ

2 ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА ПРОЕКТА

2.1 Структурирование требований к разрабатываемой системе

2.1.1 Логическое моделирование данных

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

Содержание:

• UseCase-диаграмма (UML): На диаграмме отображаются акторы (роли пользователей: Аналитик, Менеджер проекта, Финансовый директор, Администратор) и прецеденты (сценарии использования системы: «Рассчитать NPV/IRR», «Провести сценарный анализ», «Сформировать отчёт по портфелю», «Настроить интеграцию с API»). Диаграмма показывает, кто и что может делать в системе.
• Диаграмма последовательности (UML): Описывает взаимодействие объектов системы в рамках одного конкретного прецедента. Например, на диаграмме «Рассчитать NPV/IRR» показано, как объект «Форма проекта» передаёт данные объекту «Модуль расчётов», который в свою очередь запрашивает актуальные ставки у объекта «API Alpha Vantage», выполняет расчёты и возвращает результат объекту «Визуализация» для отображения на дашборде.
• Диаграмма функций: Представляет собой иерархическое дерево всех функций системы, разбитое по логическим модулям: «Модуль управления проектами», «Модуль финансовых расчётов», «Модуль риск-анализа», «Модуль визуализации и отчётности», «Модуль интеграций».

Частые ошибки и сложности: Неправильное выделение акторов и прецедентов. Распространённая ошибка — описание шагов («нажать кнопку расчёта») вместо прецедентов («рассчитать NPV»).

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

2.1.2 Конструирование модели данных

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

Содержание:

• ER-диаграмма (сущность-связь): Графическое представление сущностей (таблиц базы данных) и связей между ними. Основные сущности для данной задачи: «Инвестиционный проект» (id, название, описание, дата_старта, срок_реализации), «Финансовые потоки» (id, проект_id, дата, сумма, тип_потока), «Рыночные данные» (id, тикер, дата, цена_закрытия, объём), «Сценарий анализа» (id, название, параметры, результаты), «Пользователь» (id, роль, имя, email). Важно правильно отобразить связи: например, у одного «Инвестиционного проекта» может быть много «Финансовых потоков» (связь один-ко-многим), а у одного «Финансового потока» — одна «Дата» (связь многие-к-одному).
• Диаграмма классов (UML): Более детальное представление, включающее не только атрибуты сущностей, но и их методы (операции). Например, для класса «МодульРасчётов» атрибуты: ставка_дисконтирования, денежные_потоки; методы: рассчитатьNPV(), рассчитатьIRR(), провестиАнализЧувствительности().

Для каждой сущности необходимо дать подробное текстовое описание: перечислить все атрибуты, их типы данных (VARCHAR, DATE, DECIMAL, JSONB), указать первичные и внешние ключи.

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

Практические рекомендации: Следуйте правилам нормализации реляционных баз данных до третьей нормальной формы (3NF). Подробно опишите каждую сущность и связь в тексте, не надейтесь, что диаграмма всё объяснит сама. Укажите, какие атрибуты являются обязательными, а какие — опциональными.

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

2.2.1 План разработки ПО

Назначение: Спланировать весь процесс создания программного обеспечения, распределив задачи по времени, ресурсам и ответственным лицам.

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

1. Анализ требований и проектирование архитектуры (1 неделя).
2. Разработка фронтенд-части (интеграция библиотек D3.js, создание компонентов дашборда) (3 недели).
3. Разработка бэкенд-части (реализация модулей расчёта NPV/IRR, риск-анализа, сценарного моделирования, интеграция с API) (4 недели).
4. Интеграция фронтенда и бэкенда, настройка взаимодействия (1 неделя).
5. Модульное тестирование (тестирование отдельных функций расчёта) (1 неделя).
6. Интеграционное и системное тестирование (проверка работы всей системы в комплексе) (1 неделя).
7. Подготовка эксплуатационной документации (Руководства пользователя и администратора) (1 неделя).

Для каждого этапа указываются точные сроки, задействованные ресурсы (условные: «Frontend-разработчик», «Backend-разработчик») и ожидаемые результаты («Готовый модуль визуализации»).

Частые ошибки и сложности: Нереалистичные, завышенные сроки, не учитывающие время на отладку и правки. Полное отсутствие этапов тестирования и документирования, что является грубым нарушением жизненного цикла ПО.

Практические рекомендации: Всегда закладывайте запас времени (15-20%) на непредвиденные сложности, баги и правки научного руководителя. Помните, что тестирование — неотъемлемая часть разработки, а не опциональное дополнение.

2.2.2 Frontend-разработка

Назначение: Описать пользовательский интерфейс системы и его реализацию для каждой роли пользователя.

Содержание: Подробное описание функциональности и дизайна экранов:

• Для Аналитика: Главная страница — дашборд с графиками «Доходность портфеля», «Волатильность», таблица всех проектов с колонками NPV, IRR, ROI. Страница проекта — детализированный график денежных потоков, блок «Анализ чувствительности» со слайдерами для изменения параметров, блок «Сценарный анализ» для запуска «что если» сценариев.
• Для Менеджера проекта: Специализированная таблица с его проектами, возможность добавлять/редактировать финансовые потоки, получать уведомления о критических изменениях в показателях.
• Для Финансового директора: Стратегический дашборд с агрегированными показателями: общий NPV портфеля, распределение по отраслям, риск-профиль, прогноз доходности. Возможность экспорта отчётов в PDF/Excel.

В тексте должны быть приведены скриншоты или прототипы ключевых экранов.

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

Практические рекомендации: Создайте простые, но функциональные прототипы специально для ВКР, используя инструменты вроде Figma. Это продемонстрирует ваше понимание пользовательского опыта (UX) в контексте финансовой аналитики.

2.2.3 Backend-разработка

Назначение: Описать серверную часть приложения, её архитектуру, ключевые компоненты и алгоритмы.

Содержание: Описание должно включать:

• Архитектура: Использована модульная архитектура на основе фреймворка Django. Каждый функциональный блок (расчёты, интеграции, визуализация) выделен в отдельное приложение Django.
• Ключевые модули:**
  • Модуль расчёта NPV/IRR: Реализованы алгоритмы на основе стандартных финансовых формул с использованием библиотек NumPy и SciPy для численных методов. Функция NPV: `np.npv(discount_rate, cash_flows)`. Функция IRR: `np.irr(cash_flows)`.
  • Модуль риск-анализа: Расчёт стандартного отклонения доходности портфеля, коэффициента Шарпа. Интеграция с Alpha Vantage API для получения исторических цен и расчёта волатильности.
  • Модуль сценарного моделирования: Позволяет пользователю задавать параметры (изменение ставки дисконтирования, рост/падение доходов) и автоматически пересчитывает все показатели для каждого сценария.
  • Модуль интеграций: Класс-обёртка для работы с API Alpha Vantage, кэширование данных для снижения нагрузки на внешний сервис.

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

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

Практические рекомендации: Приводите только 2-3 самых важных и сложных фрагмента кода (не более 10-15 строк каждый). Сопровождайте их комментариями, объясняющими, ПОЧЕМУ выбран именно такой подход, а не другой, и как он соответствует требованиям финансовой точности.

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

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

Содержание: В работе реализована модель ролевого доступа (RBAC — Role-Based Access Control). Описаны все роли и их права:

• Аналитик: Может просматривать и редактировать все проекты, запускать расчёты и сценарный анализ, но не может удалять проекты или менять глобальные настройки.
• Менеджер проекта: Может просматривать и редактировать только свои проекты, добавлять финансовые потоки.
• Финансовый директор: Имеет полный read-only доступ ко всем данным и функциям анализа, может экспортировать отчёты, но не может редактировать проекты.
• Администратор: Управляет всеми пользователями, настройками системы, ролями и правами, имеет полный доступ ко всем функциям, включая удаление.

Для наглядности права представлены в виде таблицы.

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

Практические рекомендации: Используйте таблицу для представления прав доступа. По каждой функции системы задайте себе вопрос: «Кто может это делать?». Убедитесь, что в реализации кода на бэкенде (в Django) присутствует проверка прав для каждого запроса с помощью декораторов `@permission_required` или аналогов.

2.2.5 Тестирование разработанного ПО

Назначение: Подтвердить соответствие разработанного программного обеспечения заданным требованиям и оценить его качество.

Содержание: Описание применённых методов и результатов:

• Методы тестирования:
  • Модульное (Unit) тестирование: Проверка отдельных функций расчёта NPV и IRR с использованием библиотеки `unittest` для Python. Проверяется корректность расчётов на тестовых наборах данных с известным результатом. Покрытие кода — 95%.
  • Интеграционное тестирование: Проверка взаимодействия между модулями: например, корректность передачи данных от модуля интеграций (API) к модулю расчётов.
  • Приёмочное тестирование: Проверка системы конечными пользователями — 3 аналитика и 2 менеджера из ООО «ИнвестГрупп» (в рамках учебного проекта — условные лица). Оценивалась удобство интерфейса и корректность результатов.
• Результаты: В ходе тестирования было выявлено 6 дефектов различной степени критичности. Основные баги: ошибка в расчёте IRR при отрицательных потоках, проблема с обновлением данных из API. Все критические и высокие дефекты были исправлены до выпуска финальной версии. Система показала стабильную работу под нагрузкой.

Приводятся примеры 1-2 ключевых тест-кейсов.

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

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

2.2.6 План внедрения и развертывания ПО

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

Содержание: План внедрения включает следующие этапы:

1. Подготовка инфраструктуры: установка и настройка серверного оборудования или облачного инстанса (1 день).
2. Развёртывание программного обеспечения и настройка базы данных PostgreSQL (1 день).
3. Настройка интеграций с внешними API (Alpha Vantage) и внутренней системой 1С (2 дня).
4. Миграция архивных данных: перенос данных об инвестиционных проектах из Excel-файлов в новую АИС (3 дня).
5. Обучение конечных пользователей: проведение тренингов для аналитиков и менеджеров проектов (12 часов).
6. Пилотное внедрение: запуск системы для работы с одним инвестиционным проектом на срок 1 неделя для отладки.
7. Полномасштабный запуск: переход всего подразделения «Управление инвестициями» на новую систему (1 день).
8. Техническая поддержка: выделение ресурсов на сопровождение в течение первого месяца после запуска.

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

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

2.3 Руководства администратора и пользователя

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

Содержание: В соответствии с требованиями РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов» подготавливаются два отдельных руководства:

• Руководство администратора: Документ предназначен для IT-специалистов и содержит информацию о том, как установить, настроить и сопровождать систему. Включает: требования к оборудованию и ПО, пошаговую инструкцию по установке Django и зависимостей, настройке PostgreSQL, конфигурации API-ключей, управлению пользователями и ролями, резервному копированию и восстановлению. Это руководство выносится в Приложение 3.
• Руководство пользователя: Документ предназначен для конечных пользователей (аналитиков, менеджеров, финансового директора) и содержит пошаговые инструкции по работе с системой: как добавить новый инвестиционный проект, как запустить расчёт NPV/IRR, как провести сценарный анализ, как сформировать отчёт. Инструкции должны быть простыми, сопровождаться скриншотами. Это руководство выносится в Приложение 4.

Частые ошибки и сложности: Несоблюдение структуры и требований РД 50-34.698-90, объединение двух руководств в одно, отсутствие скриншотов и пошаговых инструкций.

Практические рекомендации: Чётко разделяйте документацию по ролям. Администратору нужны технические детали, пользователю — простые, понятные инструкции. Используйте скриншоты для каждого действия. Убедитесь, что структура каждого руководства соответствует ГОСТ.

2.4 Выводы по главе 2

Назначение: Подвести итоги всей проектной части, подтвердив, что все поставленные во введении задачи были успешно выполнены.

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

Частые ошибки и сложности: Студенты часто просто констатируют: «Система разработана», без оценки качества, без количественных характеристик (покрытие тестами, количество модулей) и без связи с задачами из введения.

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

Примеры/шаблоны: «В ходе проектной части была успешно разработана и протестирована полнофункциональная АИС, соответствующая всем требованиям технического задания. Реализованы ключевые модули: расчёт NPV/IRR с интеграцией рыночных данных, риск-анализ, сценарное моделирование и интерактивный дашборд. Подготовлены руководства пользователя и администратора, что обеспечивает готовность системы к внедрению и эксплуатации.»

ЭКОНОМИЧЕСКАЯ ЧАСТЬ

3 ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ ОТ РАЗРАБОТКИ ИС

3.1 Расчет затрат на разработку ИС

Назначение: Определить все прямые и косвенные затраты, связанные с созданием информационной системы.

Содержание: Для расчёта применяется методика TCO (Total Cost of Ownership — совокупная стоимость владения). Учитываются все статьи расходов на этапе разработки: оборудование, программное обеспечение, оплата труда разработчиков, начисления на заработную плату, прочие расходы (хостинг, домен).

3.2 Выбор и обоснование методики расчёта экономической эффективности

Назначение: Обосновать выбор конкретной методики для оценки эффективности проекта.

Содержание: Обоснован выбор классической методики оценки инвестиционных проектов, основанной на расчёте NPV (чистого приведённого дохода) и IRR (внутренней нормы доходности), как наиболее подходящей и общепринятой в финансовой практике. Эти показатели позволяют объективно оценить, окупятся ли первоначальные инвестиции в разработку АИС и какова будет их доходность.

3.3 Оценка затрат на разработку и внедрение АИС

3.3.1 Затраты на этапе разработки информационной системы

Назначение: Детализировать все расходы, связанные непосредственно с процессом создания программного обеспечения.

Содержание: Расчёт ведётся по статьям:

• Оборудование: используется существующий сервер — 0 руб.
• Программное обеспечение: open-source стек (React, Django, PostgreSQL) — 0 руб.
• Оплата труда разработчика: 100 часов * 1500 руб./час = 150 000 руб.
• Начисления на заработную плату (30%): 45 000 руб.
• Прочие расходы (хостинг, домен, SSL-сертификат): 5 000 руб.

Итого затраты на разработку: 200 000 руб. Формула: Оплата труда = Σ(Ti * Rj) = (60 * 1500) + (40 * 1500) = 150 000 руб.

3.3.2 Затраты на этапе внедрения

Назначение: Рассчитать расходы, связанные с вводом системы в эксплуатацию.

Содержание:

• Оборудование: 0 руб. (используется существующее).
• Обучение персонала: 12 часов * 1000 руб./час = 12 000 руб.
• Оплата специалиста по внедрению: 10 000 руб.

Итого затраты на внедрение: 22 000 руб.

3.3.3 Затраты на этапе эксплуатации

Назначение: Определить ежегодные расходы на поддержание системы в рабочем состоянии.

Содержание:

• Зарплата администратора (2 часа/мес): 24 000 руб./год.
• Профилактика и обновления: 5 000 руб./год.
• Стоимость простоев (оценка): 1 000 руб./год.

Итого годовые затраты на эксплуатацию: 30 000 руб.

3.4 Эффект от внедрения АИС

Назначение: Определить положительные изменения в деятельности компании после внедрения системы.

Содержание: Основные положительные изменения:

• Повышение доходности инвестиционного портфеля на 2% за счёт более обоснованных решений, основанных на данных в реальном времени и сценарном анализе.
• Снижение рисков за счёт системного анализа волатильности и корреляции активов.
• Экономия времени аналитиков: 20 часов/неделю * 48 недель = 960 часов/год, что эквивалентно 480 000 руб. при ставке 500 руб./час.

3.5 Экономический эффект

Назначение: Рассчитать прямой финансовый результат от внедрения системы.

Содержание: Прямой экономический эффект складывается из нескольких компонентов:

• Рост доходов от повышения доходности портфеля: При среднем размере портфеля ООО «ИнвестГрупп» в 500 000 000 руб., рост на 2% даёт дополнительный доход в размере 10 000 000 руб./год.
• Экономия на заработной плате: Высвобождение времени аналитиков позволяет перераспределить ресурсы, экономия оценивается в 480 000 руб./год.

Итого годовой экономический эффект: 10 480 000 руб. Формула: Эффект = Стоимость ресурсов до - Стоимость ресурсов после

3.6 Социальный эффект

Назначение: Оценить нематериальные выгоды, связанные с улучшением условий для сотрудников.

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

3.7 Научный эффект

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

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

3.8 Организационный эффект

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

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

3.9 Эффективность внедрения АИС (ПО ПРИМЕРУ)

Назначение: Рассчитать ключевые показатели экономической эффективности проекта.

Содержание: Расчёт основных показателей:

• NPV (чистый приведенный доход): -222 000 + (10 480 000 / 1.1) + (10 480 000 / 1.1²) + (10 480 000 / 1.1³) = **+23 800 000 руб.**
• Срок окупаемости: 222 000 / 10 480 000 * 12 ≈ **0.25 месяца (примерно 1 неделя).**
• IRR (внутренняя норма доходности): Более 1000% в год.

Формула: NPV = -IC + Σ(CFt/(1+i)^t)

3.10 Расчёт показателей экономической эффективности проекта (ПО ПРИМЕРУ)

Назначение: Привести пошаговый расчёт по выбранной методике.

Содержание: Пошаговый расчёт NPV:

1. Инвестиции (IC): 200 000 (разработка) + 22 000 (внедрение) = 222 000 руб.
2. Годовые денежные потоки (CF): 10 480 000 руб.
3. Ставка дисконтирования (i): 10% (среднерыночная).
4. NPV = -222 000 + 10 480 000/1.1 + 10 480 000/1.21 + 10 480 000/1.331 = -222 000 + 9 527 273 + 8 661 157 + 7 873 779 = **25 839 209 руб.**

Расчёт срока окупаемости: PP = IC / CF = 222 000 / 10 480 000 = 0.0212 года = 0.25 месяца.

3.11 Выводы по главе 3

Назначение: Подвести итоги экономического анализа.

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

ЗАКЛЮЧЕНИЕ

Назначение: Обобщить результаты всей работы.

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

СПИСОК ЛИТЕРАТУРЫ

1. Бригхэм, Ю.Ф. Финансовый менеджмент / Ю.Ф. Бригхэм, Дж. Хьюстон. — СПб.: Питер, 2023. — 688 с.
2. ГОСТ 34.602-2020. Информационная технология. Практика разработки. Техническое задание на создание автоматизированной системы. — Введ. 2021-01-01. — М.: Стандартинформ, 2020.
3. ГОСТ Р 7.0.100-2018. Система стандартов по информации, библиотечному и издательскому делу. Библиографическая запись. Библиографическое описание. Общие требования и правила составления. — М.: Стандартинформ, 2019.
4. РД 50-34.698-90. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Руководящие документы по разработке и сопровождению автоматизированных систем. — М.: Госстандарт СССР, 1990.
5. Ковалёв, В.В. Методы оценки инвестиционных проектов / В.В. Ковалёв. — М.: Финансы и статистика, 2022. — 320 с.
6. Методические указания по выполнению выпускной квалификационной работы для студентов направления подготовки 09.03.02 «Информационные системы и технологии». — М.: МУ имени С.Ю. Витте, 2025.
7. NumPy Documentation. URL: https://numpy.org/doc/ (дата обращения: 23.12.2025).
8. Alpha Vantage API Documentation. URL: https://www.alphavantage.co/documentation/ (дата обращения: 23.12.2025).

ПРИЛОЖЕНИЯ

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

Содержание: Полный текст технического задания, составленный в соответствии с требованиями ГОСТ 34.602-2020.

Приложение 2. Исходный код "Модуль расчёта NPV и IRR"

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

Приложение 3. Руководство администратора системы

Содержание: Руководство по установке, настройке, управлению пользователями и техническому сопровождению системы, составленное в соответствии с требованиями РД 50-34.698-90.

Приложение 4. Руководство пользователя (аналитика по инвестициям)

Содержание: Руководство по работе с системой для конечных пользователей, содержащее пошаговые инструкции и скриншоты, составленное в соответствии с требованиями РД 50-34.698-90.

Готовые инструменты и шаблоны

Шаблоны формулировок:

1. «Целью работы является разработка автоматизированной информационной системы, обеспечивающей комплексный анализ, мониторинг и управление инвестиционным портфелем ООО «ИнвестГрупп» на основе автоматизированного расчёта ключевых финансовых показателей (NPV, IRR, ROI) и инструментов сценарного моделирования.»
2. «Анализ выявил, что ручное управление портфелем в Excel приводит к потенциальным финансовым потерям до 10 млн руб. в год из-за несвоевременного реагирования на рыночные изменения и отсутствия инструментов для стратегического анализа.»

Чек-лист "Оцени свои силы":

• Знакомы ли вы с методиками расчёта NPV, IRR и их экономическим смыслом?
• Уверены ли вы в реализации финансовых алгоритмов на Python с использованием библиотек NumPy/SciPy?
• Можете ли вы настроить интеграцию с API Alpha Vantage для получения рыночных данных?
• Есть ли у вас запас времени (2-3 недели) на исправление замечаний научного руководителя?
• Можете ли вы самостоятельно составить техническое задание по ГОСТ 34.602-2020 без шаблонов?

И что же дальше? Два пути к успешной защите

Путь 1: Самостоятельный. Вы — целеустремленный и технически подкованный студент, готовый принять этот вызов. Вам предстоит освоить финансовую теорию, проектировать сложную ИТ-систему, реализовывать нетривиальные алгоритмы расчёта и визуализации, и проводить экономический анализ. Этот путь потребует от вас не менее 150-200 часов упорного труда и высокой стрессоустойчивости.

Путь 2: Профессиональный. Вы выбираете разумное решение: экономию времени, гарантию качества и уверенность в результате. Наши эксперты возьмут на себя всю техническую и методическую нагрузку, а вы получите готовую ВКР, соответствующую всем требованиям МУИВ.

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

Нужна ВКР по этой теме? Ответим за 10 минут!
Telegram: @Diplomit
Телефон/WhatsApp: +7 (987) 915-99-32, Email: admin@diplom-it.ru

Оформите заказ онлайн: Заказать ВКР МУИВ

ЗАКЛЮЧЕНИЕ

Написание ВКР МУИВ на тему «Разработка автоматизированной информационной системы для управления портфелем инвестиций предприятия» — это задача высочайшей сложности и практической ценности. Она требует глубокой проработки: от анализа финансовых теорий до реализации сложных алгоритмов и расчёта NPV. Написание ВКР МУИВ — это марафон. Вы можете пробежать его самостоятельно или доверить задачу профессионалам, которые приведут вас к финишу с лучшим результатом и без лишних потерь. Если вы выбираете надёжность и экономию времени — мы готовы помочь вам прямо сейчас.

Полезные ссылки:

• Перечень тем с руководствами по написанию для 38.03.05 Бизнес-информатика Направленность: Цифровая экономика, МУИВ
• Все готовые работы
• Условия работы и как сделать заказ
• Наши гарантии
• Отзывы наших клиентов