Пишем курсовую «Стратегический план создания ИС» от введения до заключения.

Введение

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

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

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

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

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

Глава 1. Анализ бизнес-контекста как фундамент для будущей системы

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

Представим компанию «ГлобалЛогистик» — крупного дистрибьютора с центральным офисом в Москве и десятками складов по всей стране. Ее текущие проблемы («as-is») включают медленную обработку заказов из-за разрозненных систем учета, высокие издержки на логистику из-за неоптимальных маршрутов и отсутствие единой картины по остаткам на складах. Эти проблемы напрямую мешают росту компании.

Руководство «ГлобалЛогистик» ставит перед собой следующие стратегические бизнес-цели:

1. Увеличить скорость обработки клиентских заказов на 30%.
2. Сократить общие издержки на логистику и складское хранение на 15%.
3. Обеспечить топ-менеджмент актуальными данными о состоянии бизнеса в режиме реального времени.

Ключевой шаг стратегического планирования — это перевод этих бизнес-целей на язык проектных задач. Таким образом, цели проекта по созданию ИС формулируются следующим образом:

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

Этот переход от языка бизнеса («увеличить скорость») к языку проекта («разработать модуль») является фундаментом, на котором строится вся дальнейшая работа по проектированию системы.

Глава 1. Формулирование функциональных и нефункциональных требований

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

Функциональные требования (Что делает система?)

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

• Модуль «Управление заказами»:
  • Регистрация нового заказа от клиента с указанием номенклатуры, объема и адреса доставки.
  • Автоматическая проверка наличия товара на ближайшем складе.
  • Изменение статуса заказа (Принят, Комплектуется, Отгружен, Доставлен).
• Модуль «Складской учет»:
  • Ведение учета остатков товаров в разрезе складов.
  • Автоматическое списание товаров при отгрузке.
  • Формирование заявок на пополнение склада при достижении минимального порога.
• Модуль «Пользователи и роли»:
  • Возможность регистрации пользователей с ролями: «Менеджер по продажам», «Кладовщик», «Логист», «Администратор».
  • Назначение прав доступа к разным модулям в зависимости от роли.
• Модуль «Отчетность»:
  • Генерация ежемесячного отчета по объему продаж.
  • Формирование отчета по складским остаткам на любую дату.

Нефункциональные требования (Как работает система?)

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

• Производительность: Система должна обеспечивать время отклика на основные операции (например, создание заказа) не более 2 секунд при одновременной работе до 1000 пользователей.
• Надежность: Доступность системы должна составлять не менее 99.9%, что предполагает минимальное время простоя.
• Безопасность: Все данные, передаваемые между клиентом и сервером, должны шифроваться с использованием протокола TLS. Доступ к данным должен быть строго ограничен ролевой моделью.
• Масштабируемость: Архитектура должна позволять увеличение нагрузки (количества пользователей, заказов) в 2 раза без кардинальной переработки системы.
• Удобство использования (Usability): Интерфейс системы должен быть интуитивно понятным, чтобы новый сотрудник мог освоить основные операции в течение одного рабочего дня.

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

Глава 2. Проектирование архитектуры и выбор технологического стека

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

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

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

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

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

• Язык программирования (Backend): Java с использованием фреймворка Spring Boot. Этот выбор обоснован высокой производительностью, большим сообществом, надежностью и отличной поддержкой для создания микросервисных приложений.
• База данных (СУБД): PostgreSQL. Это мощная, бесплатная реляционная СУБД, которая хорошо справляется с большими объемами данных и сложными запросами, что необходимо для аналитики и учета. Для кэширования часто запрашиваемых данных будет использоваться Redis.
• Интерфейс (Frontend): React.js. Популярная JavaScript-библиотека для создания динамичных и отзывчивых пользовательских интерфейсов.
• Оркестрация и развертывание: Docker для контейнеризации сервисов и Kubernetes для управления этими контейнерами. Это стандарт де-факто для развертывания микросервисных приложений, обеспечивающий масштабируемость и автоматическое восстановление после сбоев.

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

Глава 2. Разработка поэтапного плана внедрения проекта

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

Процесс создания ИС «ГлобалЛогистик» разбивается на следующие логические этапы:

1. Детальное проектирование и прототипирование (4 недели): На этом этапе команда системных аналитиков и UX/UI-дизайнеров готовит подробные спецификации для каждого микросервиса и создает интерактивные прототипы интерфейсов. Ключевая веха: утверждение дизайн-макетов и технического задания заказчиком.
2. Разработка базовой инфраструктуры и первых сервисов (8 недель): Команда разработки (DevOps и backend) настраивает среду развертывания (Kubernetes), создает первые ключевые сервисы (пользователи, заказы) и настраивает их взаимодействие. Ключевая веха: работающее API для базовых операций.
3. Параллельная разработка функциональных модулей (12 недель): Разные команды одновременно работают над сервисами склада, логистики и отчетности. Frontend-команда разрабатывает пользовательский интерфейс, подключаясь к готовым API. Ключевая веха: завершение разработки основного функционала.
4. Интеграционное тестирование и отладка (6 недель): QA-инженеры проводят комплексное тестирование всей системы, проверяя корректность взаимодействия всех микросервисов и соответствие функциональным и нефункциональным требованиям. Ключевая веха: отчет о тестировании с перечнем исправленных дефектов.
5. Пилотное внедрение и обучение персонала (4 недели): Система разворачивается на одном из складов «ГлобалЛогистик» для работы в реальных условиях. Проводится обучение ключевых пользователей. Собирается обратная связь. Ключевая веха: успешное завершение пилотного этапа.
6. Полномасштабное развертывание и поддержка (постоянно): Система поэтапно внедряется во всех подразделениях компании. Формируется команда поддержки для решения возникающих вопросов и доработки функционала.

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

Глава 3. Оценка рисков и разработка бюджета проекта

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

Оценка рисков проекта

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

• Технические риски:
  • Риск: Сложность интеграции выбранных технологий.
  • План минимизации: Проведение на раннем этапе «Proof of Concept» (доказательство концепции) для проверки взаимодействия ключевых компонентов стека.
• Организационные риски:
  • Риск: Сопротивление персонала внедрению новой системы.
  • План минимизации: Проведение обучающих семинаров, вовлечение ключевых будущих пользователей в процесс тестирования, разработка понятной документации.
  • Риск: Уход ключевого разработчика из команды.
  • План минимизации: Ведение подробной документации по коду, парное программирование, распределение знаний внутри команды.
• Финансовые риски:
  • Риск: Превышение бюджета из-за неверной первоначальной оценки.
  • План минимизации: Разбиение проекта на короткие итерации с регулярной переоценкой оставшихся работ, закладывание резерва (15-20%) в бюджет на непредвиденные расходы.

Бюджетирование проекта

Детальный бюджет — это финансовое выражение всего плана работ. Он должен включать все статьи расходов на создание и запуск системы. Для проекта «ГлобалЛогистик» бюджет будет состоять из следующих основных статей:

1. Фонд оплаты труда (ФОТ): Самая значительная часть расходов. Включает зарплату всей проектной команды (менеджер проекта, аналитики, backend/frontend разработчики, DevOps, QA-инженеры) на весь срок разработки.
2. Затраты на оборудование и ПО:
   • Аренда или покупка серверов для разработки, тестирования и продуктивной эксплуатации.
   • Стоимость лицензий на любое коммерческое ПО (если используется).
3. Затраты на внедрение и обучение: Включают командировочные расходы для обучения персонала в региональных филиалах и оплату работы тренеров.
4. Расходы на последующую поддержку: Затраты на команду, которая будет поддерживать и развивать систему после ее запуска (обычно оценивается как 15-20% от стоимости разработки в год).
5. Резерв на риски: Сумма, заложенная на случай возникновения непредвиденных проблем (как правило, 15% от общей стоимости).

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

Заключение

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

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

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

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

Список использованных источников

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

Оформление должно строго соответствовать принятым академическим стандартам, например, ГОСТ Р 7.0.5-2008 или ГОСТ Р 7.0.100-2018. Как правило, источники располагаются в алфавитном порядке и нумеруются.

Пример оформления различных типов источников (по ГОСТ):

• Книга:
  Иванов, И. И. Проектирование информационных систем : учебное пособие / И. И. Иванов. – Москва : КноРус, 2023. – 250 с. – Текст : непосредственный.
• Статья из журнала:
  Петров, П. П. Особенности применения микросервисной архитектуры / П. П. Петров // Вестник информационных технологий. – 2024. – № 2. – С. 45-52. – Текст : непосредственный.
• Электронный ресурс:
  Oracle : [сайт]. – URL: https://www.oracle.com/ (дата обращения: 10.08.2025). – Текст : электронный.

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

Список использованной литературы

1. Майкл Оутей, Поль Конте SQL Server 2000 СПб.: Питер; К.: Издательская группа BHV, 2002. 992с. :ил.
2. В. Фаронов Программирование баз данных в Delphi 7. Учебный курс. Спб.: Питер, 2006. 459с.:ил.
3. А.Я. Архангельский Программирование в Delphi 7. М.: ООО «Бином-Пресс», 2003 г. 1152с.:ил.
4. И.Ю. Баженова Delphi 7 Самоучитель программиста М.: «Кудиц-Образ», 2003 448с.:ил.