Проектирование и реализация информационной системы для проектного бюро на Microsoft Access: Комплексный подход с учетом стандартов и методологий

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

Эта курсовая работа посвящена фундаментальным аспектам проектирования и реализации информационной системы (ИС) для предприятия типа «проектное бюро», используя мощный и доступный инструментарий Microsoft Access. Мы не просто создадим базу данных, а проложим маршрут от первичного анализа организационной структуры и бизнес-процессов до детальной инфологической и физической модели, с глубоким погружением в методологии структурного системного анализа и строгим соблюдением отраслевых стандартов. Цель работы — предоставить исчерпывающее руководство, которое не только демонстрирует техническую реализацию, но и обосновывает каждое проектное решение, превращая сложность задачи в ясную, логически выстроенную структуру, готовую к применению на практике.

1. Проектное бюро: Организационная структура и автоматизируемые бизнес-процессы

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

1.1 Типы организационных структур и их применимость в проектном бюро

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

• Линейная структура: Характеризуется строгой вертикальной иерархией, где каждый сотрудник подчиняется только одному руководителю. Проста и понятна, но страдает от низкой гибкости и медленной реакции на изменения.
• Функциональная структура: Объединяет сотрудников по их профессиональным функциям (например, отдел проектирования, отдел маркетинга). Эффективна для специализированных задач, но может усложнить межфункциональное взаимодействие, особенно в многопроектной среде, где координация требует прохождения через верхние эшелоны управления. Такой подход уместен для небольших, несложных проектов, выполняемых по стандартным технологиям.
• Линейно-функциональная структура: Комбинирует линейные и функциональные принципы, сохраняя единоначалие при усилении роли функциональных подразделений.
• Дивизионная структура: Подходит для крупных компаний, разделенных по продуктам, регионам или клиентам.
• Комбинированная структура: Представляет собой гибрид, сочетающий элементы разных типов.
• Матричная структура: Часто применяется в проектных организациях и компаниях, занимающихся разработкой программного обеспечения. Она подразумевает двойное подчинение: сотрудник одновременно подчиняется функциональному руководителю (например, руководителю отдела разработки) и руководителю проекта. Эта структура идеально подходит для проектов с высокой степенью изменчивости и использованием сложных технологий, обеспечивая гибкость и эффективное использование специализированных ресурсов.
• Проектно-ориентированная структура: В ней специалисты полностью выделены для работы над конкретным проектом и подчиняются исключительно руководителю этого проекта. Это наиболее оптимальный вариант для компаний, чей основной бизнес — это реализация проектов, поскольку такая структура обеспечивает максимальную концентрацию ресурсов и внимания на достижении проектных целей.

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

1.2 Ключевые бизнес-процессы проектного бюро, подлежащие автоматизации

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

• Управление проектами:
  • Создание и редактирование проектов: Ввод основных данных о проекте (название, описание, заказчик, руководитель, сроки, бюджет).
  • Ведение реестра проектов: Централизованное хранение информации обо всех текущих и завершенных проектах, их статусах, ключевых параметрах.
  • Планирование задач и ресурсов: Декомпозиция проекта на отдельные задачи, определение их последовательности, зависимостей и необходимых ресурсов (человеческих, материальных).
  • Назначение исполнителей и распределение ролей: Привязка конкретных сотрудников к задачам, определение их ролей и ответственности.
  • Установление сроков и приоритетов: Определение дедлайнов для задач и проекта в целом, ранжирование задач по степени важности.
  • Отслеживание прогресса: Мониторинг выполнения задач, фиксация статусов (начато, в работе, завершено), процентов выполнения.
• Управление рисками и изменениями: Идентификация потенциальных рисков, оценка их влияния, разработка мер по снижению, фиксация и управление изменениями в проекте.
• Управление финансовыми контурами и расчет рисков: Контроль бюджетов проектов, учет затрат, формирование финансовых отчетов.
• Коммуникация между участниками проекта: Обеспечение эффективного обмена информацией, документами, комментариями внутри проектной команды.

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

1.3 Роль Microsoft Access в автоматизации малых и средних проектных задач

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

Благодаря своей простоте и наличию встроенных шаблонов, Access позволяет быстро развернуть систему, способную:

• Управлять сотрудниками: Создавать записи о сотрудниках, их должностях, контактных данных.
• Управлять проектами: Вести детализированные данные о каждом проекте, включая его описание, сроки, бюджет и ответственных.
• Управлять задачами: Декомпозировать проекты на задачи, назначать исполнителей, устанавливать сроки и отслеживать их статусы.
• Формировать отчеты: Автоматически генерировать отчеты типа «Открытые проекты», «Сведения о задачах», «Адресная книга сотрудника», что значительно упрощает контроль и анализ.

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

2. Методологии структурного системного анализа для проектирования ИС

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

2.1 Основы структурного анализа: принципы и методы

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

1. Принцип «разделяй и властвуй»: Наиболее фундаментальный подход, предписывающий разбивать сложную проблему на более мелкие, легко управляемые и анализируемые задачи. Это позволяет постепенно углубляться в детали, не теряя при этом общую картину.
2. Иерархическое упорядочение: Части системы организуются в древовидные структуры, где каждый уровень представляет собой детализацию вышестоящего. Обычно рекомендуется ограничивать количество элементов на каждом уровне абстракции от 3 до 7, чтобы избежать чрезмерной сложности и сохранить ясность.
3. Строгие формальные правила записи: Использование стандартизированных нотаций и графических средств, что обеспечивает однозначность интерпретации и универсальность модели.

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

2.2 Методология SADT (IDEF0) для функционального моделирования

Одной из наиболее известных и широко используемых методик структурного проектирования является методология SADT (Structured Analysis and Design Technique), разработанная Дугласом Т. Россом. Впоследствии она получила официальный статус федерального стандарта обработки информации (FIPS) США под названием IDEF0.

IDEF0 (Integration Definition for Function Modeling) позволяет представить систему как совокупность взаимодействующих работ (функций). В основе модели IDEF0 лежит графическое изображение, где каждая работа (функция) представлена блоком (прямоугольником), а взаимодействие между работами — стрелками. Эти стрелки имеют строго определенное значение:

• Вход (Input): Материалы или информация, которые преобразуются работой.
• Управление (Control): Условия, правила или ограничения, регулирующие выполнение работы.
• Выход (Output): Результат выполнения работы.
• Механизм (Mechanism): Ресурсы (люди, инструменты, системы), используемые для выполнения работы.

Модель IDEF0 строится иерархически. На верхнем уровне (контекстная диаграмма, A-0) система представляется одним блоком, дающим общий обзор ее функции. Затем этот блок декомпозируется на следующем уровне на несколько дочерних блоков, каждый из которых представляет собой подфункцию родительского блока. Этот процесс декомпозиции продолжается до тех пор, пока не будет достигнут необходимый уровень детализации. Например, для проектного бюро функция «Управление проектами» может быть декомпозирована на «Инициация проекта», «Планирование проекта», «Исполнение проекта», «Мониторинг и контроль проекта», «Завершение проекта». Каждая из этих подфункций далее детализируется, обеспечивая полную прозрачность и понимание всех процессов.

2.3 Дополнительные методы структурного моделирования

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

• Диаграммы потоков данных (DFD, Data Flow Diagrams): DFD используются для наглядного изображения движения информации (данных) в системе, а также для отображения источников, преобразований и потребителей этих данных. Они состоят из четырех основных элементов:
  • Процессы (Process): Функции, которые преобразуют входные данные в выходные.
  • Хранилища данных (Data Store): Места, где данные хранятся (например, базы данных, файлы).
  • Внешние сущности (External Entity): Источники или получатели данных, находящиеся за пределами системы (например, заказчик, поставщик).
  • Потоки данных (Data Flow): Стрелки, показывающие движение данных между элементами.

DFD-диаграммы часто дополняют модели IDEF0, позволяя выявить последовательность событий в системе и связанные с ними данные. Например, DFD для проектного бюро может показать, как данные о новом проекте поступают от Заказчика, обрабатываются в Процессе «Инициация проекта», сохраняются в Хранилище данных «Реестр проектов» и используются Руководителем проекта.

• IDEF3 (Process Description Capture Method): Эта методология фокусируется на моделировании последовательности выполнения действий. Она позволяет описывать сценарии процессов, выявлять различные пути их выполнения и фиксировать временные и логические зависимости между событиями. IDEF3 особенно полезна, когда необходимо детально проработать порядок выполнения шагов в бизнес-процессе, включая возможные ветвления и циклы.

• IDEF1X (Data Modeling Method): В отличие от IDEF0, которая моделирует функции, IDEF1X используется для информационного моделирования данных. Она является стандартом для построения реляционных баз данных, фокусируясь на сущностях, их атрибутах и связях. IDEF1X позволяет создавать логические модели данных, которые затем могут быть преобразованы в физическую структуру базы данных.

Комплексное применение этих методов (IDEF0 для функций, DFD для потоков данных, IDEF3 для последовательности действий и IDEF1X для данных) обеспечивает всесторонний взгляд на проектируемую ИС, что является критически важным для создания надежной, эффективной и соответствующей требованиям системы, ведь какой важный нюанс здесь упускается, если не учитывать все эти аспекты?

3. Проектирование инфологической и реляционной базы данных

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

3.1 Инфологическое (концептуальное) проектирование: ER-модель

Инфологическое проектирование — это первый и один из наиболее важных этапов. Его цель — построение семантической модели предметной области, которая представляет собой информационную модель высокого уровня абстракции. Эта модель должна быть понятна как специалистам, так и заказчику, и главное — она полностью независима от конкретной СУБД или технологии реализации. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» часто используются как синонимы.

Для описания предметной области на инфологическом уровне наиболее часто используется модель «сущность-связь» (ER-модель, Entity-Relationship model). ER-диаграмма (ERD) — это графическое представление ER-модели, которое наглядно показывает, какие данные есть в системе и как они связаны между собой.

Основные элементы ER-модели:

• Сущность (Entity): Это объект, о котором в системе необходимо накапливать информацию. Сущность должна быть чем-то реальным или концептуальным, что можно отличить от других объектов. Например, для проектного бюро сущностями могут быть: «Проекты», «Задачи», «Сотрудники», «Заказчики», «Ресурсы», «Сроки», «Бюджеты». На диаграммах сущность обычно изображается в виде прямоугольника.
• Атрибут (Attribute): Это поименованная характеристика сущности, определяющая её свойства. Атрибуты описывают данные, которые будут храниться для каждой сущности. Например, для сущности «Сотрудник» атрибутами могут быть: «ФИО», «Должность», «Электронная почта», «Телефон». Атрибуты могут быть простыми (неделимыми, как «ФИО») или составными (состоящими из нескольких простых, как «Адрес» из «Улицы», «Города», «Индекса»).
• Связь (Relationship): Это ассоциация между двумя или более сущностями, выражающая их взаимоотношения. Связи описывают, как сущности взаимодействуют друг с другом. Типы связей определяются их кардинальностью (количеством возможных связей):
  • «Один-к-одному» (1:1): Каждому экземпляру одной сущности соответствует один экземпляр другой сущности, и наоборот (например, «Сотрудник» имеет «ПаспортныеДанные»).
  • «Один-ко-многим» (1:N или 1:M): Одному экземпляру одной сущности соответствует множество экземпляров другой, но каждому экземпляру второй сущности соответствует только один экземпляр первой (например, «РуководительПроекта» управляет «МножествомПроектов»).
  • «Многие-ко-многим» (M:N): Множеству экземпляров одной сущности соответствует множество экземпляров другой, и наоборот (например, «Сотрудник» может быть назначен на «МножествоЗадач», и «Задача» может иметь «МножествоИсполнителей»).

На ER-диаграммах связи обозначаются линиями, соединяющими сущности, с указанием кардинальности с помощью специальной нотации (например, «вороньи лапки» для «многие»).

Пример ER-диаграммы для проектного бюро:
Представим основные сущности:

• Проекты: (IDПроекта, Название, Описание, ДатаНачала, ДатаОкончания, Бюджет)
• Задачи: (IDЗадачи, НазваниеЗадачи, Описание, Срок, Статус, IDПроекта (внешний ключ))
• Сотрудники: (IDСотрудника, ФИО, Должность, ЭлектроннаяПочта)
• Ресурсы: (IDРесурса, НазваниеРесурса, Тип, Доступность)

Связи:

• «Проекты» — «один-ко-многим» — «Задачи» (один проект включает много задач).
• «Сотрудники» — «многие-ко-многим» — «Задачи» (один сотрудник может выполнять много задач, и одна задача может быть назначена многим сотрудникам). Для реализации этой связи потребуется промежуточная сущность, например, «НазначениеЗадач».
• «Задачи» — «многие-ко-многим» — «Ресурсы» (одна задача может требовать несколько ресурсов, и один ресурс может использоваться в нескольких задачах). Также потребует промежуточную сущность.

3.2 Логическое проектирование: Реляционная модель данных и нормализация

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

• Строки (кортежи) — это записи об отдельных объектах (например, один конкретный проект, один сотрудник).
• Столбцы (атрибуты) — это характеристики этих объектов (например, название проекта, ФИО сотрудника).

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

1. Устранить избыточность данных: Предотвратить дублирование информации, которая может храниться в нескольких местах.
2. Обеспечить целостность данных: Гарантировать точность и непротиворечивость данных, предотвращая аномалии при вставке, удалении или обновлении.
3. Повысить гибкость и масштабируемость: Упростить изменение структуры базы данных в будущем.

Нормализация включает в себя последовательное применение ряда нормальных форм (НФ).

3.3 Нормальные формы реляционных баз данных (НФ)

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

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

• Вторая нормальная форма (2НФ):
  • Таблица должна находиться в 1НФ.
  • Каждый неключевой атрибут должен функционально полно зависеть от всего первичного ключа. Это означает, что если первичный ключ составной (состоит из нескольких атрибутов), то ни один неключевой атрибут не должен зависеть только от части первичного ключа.
  • Пример: Если у нас есть таблица «НазначениеЗадач» (IDПроекта, IDСотрудника, IDЗадачи, СтатусЗадачи, ФИОСотрудника). Первичный ключ — это (IDПроекта, IDСотрудника, IDЗадачи). ФИОСотрудника зависит только от IDСотрудника, а не от всего составного ключа. Для достижения 2НФ необходимо вынести информацию о сотрудниках в отдельную таблицу «Сотрудники» (IDСотрудника, ФИОСотрудника) и оставить в «НазначениеЗадач» только IDСотрудника в качестве внешнего ключа.

• Третья нормальная форма (3НФ):
  • Таблица должна находиться во 2НФ.
  • Все неключевые атрибуты не должны иметь транзитивных зависимостей от первичного ключа. Это означает, что неключевой атрибут не должен зависеть от другого неключевого атрибута.
  • Пример: Таблица «Проекты» (IDПроекта, НазваниеПроекта, IDРуководителя, ФИОРуководителя). ФИОРуководителя зависит от IDРуководителя, а не напрямую от IDПроекта. Для достижения 3НФ, ФИОРуководителя нужно вынести в отдельную таблицу «Руководители» (IDРуководителя, ФИОРуководителя), а в таблице «Проекты» оставить только IDРуководителя как внешний ключ.

3.4 Продвинутые нормальные формы: НФБК, 4НФ и 5НФ

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

• Нормальная форма Бойса-Кодда (НФБК, BCNF):
  • Отношение находится в НФБК, если оно находится в 3НФ, и каждый детерминант (атрибут или набор атрибутов, от которого функционально зависят другие атрибуты) является потенциальным ключом.
  • НФБК устраняет аномалии, которые могут возникать, когда таблица в 3НФ имеет несколько перекрывающихся потенциальных ключей. Это более строгая форма, чем 3НФ, и всегда предпочтительна, когда это возможно. Она гарантирует, что каждый неключевой атрибут зависит только от полного первичного ключа и никаких других детерминантов.

• Четвертая нормальная форма (4НФ):
  • Отношение находится в 4НФ, если оно находится в НФБК и не содержит нетривиальных многозначных зависимостей.
  • Многозначная зависимость возникает, когда в одной таблице содержатся несколько независимых атрибутов, которые зависят от третьего атрибута, но не друг от друга. Это приводит к избыточности.
  • Пример: Таблица «Сотрудник_Навыки_Языки» (IDСотрудника, Навык, Язык). Если сотрудник имеет несколько навыков и несколько языков, и эти множества независимы друг от друга, то для каждого сочетания навыка и языка придется создавать отдельную запись, что приводит к дублированию. Для достижения 4НФ, такие данные должны быть разделены на две отдельные таблицы: «Сотрудник_Навыки» (IDСотрудника, Навык) и «Сотрудник_Языки» (IDСотрудника, Язык).

• Пятая нормальная форма (5НФ, или нормальная форма проекции-соединения, PJ/NF):
  • Отношение находится в 5НФ, если оно находится в 4НФ и не может быть декомпозировано на меньшие таблицы без потери информации. Эта форма устраняет зависимости соединения, которые возникают из-за сложных взаимосвязей между атрибутами, не выражающихся как функциональные или многозначные зависимости.
  • 5НФ направлена на минимизацию избыточности до абсолютного минимума, что обычно достигается путем декомпозиции таблицы таким образом, чтобы каждая новая таблица представляла собой более простую связь. В реальных проектах 5НФ используется редко из-за сложности определения всех зависимостей соединения и потенциального увеличения сложности запросов. Однако её понимание важно для полного охвата теоретических основ проектирования баз данных.

Процесс нормализации является итеративным. Часто достаточно достичь 3НФ или НФБК, что обеспечивает хороший баланс между целостностью данных и производительностью системы, но полное понимание всех форм позволяет выявлять и устранять скрытые проблемы, которые могут проявиться только на поздних этапах эксплуатации.

3.5 Физическое проектирование в Microsoft Access

Физическое проектирование — это заключительный этап, на котором создается конкретная схема базы данных для выбранной СУБД. На этом этапе определяются типы данных для каждого атрибута, методы доступа к данным, техники индексирования, а также физическое размещение данных на диске.

В Microsoft Access процесс физического проектирования базы данных осуществляется в значительной степени автоматизированно средствами самой СУБД. Пользователь определяет:

• Имена таблиц: Соответствующие сущностям из логической модели.
• Имена полей (столбцов): Соответствующие атрибутам.
• Типы данных: Для каждого поля (например, «Текстовый», «Числовой», «Дата/Время», «Логический», «Счетчик», «OLE-объект», «Вложение»). Access автоматически управляет физическим хранением данных и индексацией.
• Первичные ключи: Для каждой таблицы.
• Внешние ключи: Для установления связей между таблицами.
• Ограничения целостности: Access позволяет задавать правила ссылочной целостности, каскадного обновления и удаления записей.

Пример физической реализации:
Основываясь на ER-модели, в MS Access будут созданы следующие таблицы:

1. Проекты:
   • IDПроекта (Счетчик, Первичный ключ)
   • НазваниеПроекта (Короткий текст)
   • Описание (Длинный текст)
   • ДатаНачала (Дата/Время)
   • ДатаОкончания (Дата/Время)
   • Бюджет (Денежный)
   • IDРуководителя (Числовой, Внешний ключ к таблице «Сотрудники»)

1. Сотрудники:
   • IDСотрудника (Счетчик, Первичный ключ)
   • ФИО (Короткий текст)
   • Должность (Короткий текст)
   • ЭлектроннаяПочта (Короткий текст)

1. Задачи:
   • IDЗадачи (Счетчик, Первичный ключ)
   • НазваниеЗадачи (Короткий текст)
   • Описание (Длинный текст)
   • СрокВыполнения (Дата/Время)
   • Статус (Короткий текст)
   • IDПроекта (Числовой, Внешний ключ к таблице «Проекты»)

1. НазначенияЗадач (промежуточная таблица для связи M:N между Сотрудниками и Задачами):
   • IDНазначения (Счетчик, Первичный ключ)
   • IDСотрудника (Числовой, Внешний ключ к таблице «Сотрудники»)
   • IDЗадачи (Числовой, Внешний ключ к таблице «Задачи»)
   • ДатаНазначения (Дата/Время)
   • ДатаЗавершения (Дата/Время)

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

4. Особенности реализации ИС на Microsoft Access

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

4.1 Преимущества использования Microsoft Access

Microsoft Access является функционально полной реляционной СУБД, входящей в состав пакета Microsoft Office, и предоставляет широкий спектр средств для определения, обработки и управления данными. Его популярность обусловлена следующими преимуществами:

• Простота и гибкость: Access интуитивно понятен и удобен для пользователей, даже с минимальным опытом в программировании. Он позволяет быстро накапливать и систематизировать информацию, легко выполнять поиск, сортировку и фильтрацию данных. Благодаря встроенным конструкторам форм и отчетов, пользователи могут быстро создавать наглядные интерфейсы для ввода и представления данных, что значительно ускоряет разработку.
• Интеграция с другими приложениями Microsoft Office: Одним из наиболее значимых преимуществ является бесшовная интеграция с другими продуктами Microsoft Office, такими как Excel, Word и Outlook. Это упрощает управление и анализ данных, позволяя легко импортировать данные из Excel для их дальнейшей обработки в Access или экспортировать отчеты в Word для форматирования и печати.
• Экономическая эффективность: Для организаций и пользователей, уже имеющих лицензию на пакет Microsoft Office, Access не требует дополнительных затрат на приобретение. Это делает его крайне привлекательным решением для малого и среднего бизнеса с ограниченным бюджетом.
• Поддержка многопользовательского режима: Access позволяет организовать совместную работу нескольких пользователей с одной базой данных, что важно для коллективной работы в проектном бюро. Система поддерживает настройку прав доступа, что позволяет контролировать, кто может просматривать, изменять или удалять данные. Однако стоит отметить, что хотя официально Access поддерживает до 255 одновременно работающих пользователей, для обеспечения оптимальной производительности в реальных условиях, особенно при работе с файловыми базами данных по сети, рекомендуется использовать его с меньшим числом активных пользователей, обычно до 10–20.

4.2 Недостатки и ограничения Microsoft Access

Несмотря на свои преимущества, Microsoft Access имеет ряд существенных недостатков, которые необходимо учитывать при выборе платформы:

• Ограниченная масштабируемость и производительность: Access предназначен для баз данных небольшого и среднего размера. При работе с большими и сложными наборами данных, особенно при значительном количестве одновременных пользователей или использовании по сети, могут возникать серьезные проблемы с производительностью. Скорость выполнения запросов и генерации отчетов может значительно снижаться, что замедляет работу пользователей.
• Ограничения на объем информации: Файлы баз данных в Microsoft Access (форматы .accdb или .mdb) имеют жесткое ограничение по размеру — не более 2 ГБ. Это ограничение включает в себя все объекты базы данных (таблицы, запросы, формы, отчеты, макросы, модули) и данные. Для обхода этого ограничения рекомендуется либо связывать таблицы из нескольких баз данных Access (каждая до 2 ГБ), либо, что более эффективно для растущих систем, переходить на серверные решения, такие как Microsoft SQL Server.
• Проблемы с совместимостью и переносимостью: Базы данных Access разработаны преимущественно для операционной системы Windows. Это может создавать сложности при попытке развернуть систему в кроссплатформенной среде или интегрировать ее с приложениями, работающими на других ОС.
• Безопасность: Хотя Access 2010 и последующие версии внедрили улучшенные технологии шифрования, Access по своей сути является файловой базой данных, что делает её более уязвимой по сравнению с клиент-серверными СУБД. Наилучший способ защиты конфиденциальных данных в Access — хранение таблиц на более надежном сервере, например, с использованием Microsoft SQL Server, а Access использовать только как интерфейс к этим данным.

4.3 Технические характеристики и функционал MS Access

Access предоставляет богатый набор функций для разработки ИС:

• Создание объектов:
  • Таблицы: Для хранения данных с возможностью определения типов данных, первичных и внешних ключей, а также правил валидации.
  • Запросы: Для извлечения, фильтрации, сортировки, объединения и модификации данных. Access поддерживает как графические QBE-запросы (Query By Example), так и SQL-запросы (Structured Query Language). Различают запросы-выборки (для получения данных) и запросы-действия (для изменения данных: добавление, обновление, удаление, создание таблиц).
  • Формы: Для удобного ввода, просмотра и редактирования данных с пользовательским интерфейсом. Допускает до 754 элементов управления и разделов в форме или отчете.
  • Отчеты: Для представления данных в печатном виде или для анализа, с возможностью группировки, сортировки (до 10 полей/выражений) и вычисления итогов.
• Макросы: Access поддерживает до 999 макрокоманд в одном макросе, что позволяет автоматизировать рутинные задачи без написания кода.
• VBA (Visual Basic for Applications): Для более сложной логики и расширения функционала Access предоставляет мощный язык программирования VBA, позволяющий создавать пользовательские функции, процедуры и обработчики событий.
• Проекты Access (ADP): С помощью ADP Access может напрямую подключаться к базе данных Microsoft SQL Server, позволяя изменять структуру объектов SQL Server и использовать хранимые процедуры SQL Server, что значительно расширяет его возможности и масштабируемость.
• Ограничения SQL: Длина SQL-инструкции, используемой как свойство Recordsource (источник записей) или Rowsource (источник строк), может достигать 32750 символов.

Таким образом, Access является отличным выбором для прототипирования, быстрой разработки и реализации небольших ИС для проектных бюро, особенно при наличии специалистов с базовыми навыками работы в Office. Однако при планировании роста и увеличении объемов данных необходимо заранее предусмотреть стратегии миграции на более мощные серверные СУБД, что позволит избежать многих проблем в будущем.

5. Функциональные требования и пользовательские интерфейсы ИС проектного бюро

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

5.1 Определение функциональных требований

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

Этапы проектирования пользовательского интерфейса (UI) тесно связаны с определением функциональных требований:

1. Выбор темы и стиля: Определение общего визуального стиля и эстетики системы, которая должна соответствовать корпоративной культуре и быть интуитивно понятной.
2. Создание пользовательских профилей и сценариев:
   • Пользовательский профиль: Подробное описание базовых характеристик целевых пользователей (демографические данные, опыт работы с ПО, цели, ожидания, мотивации, рабочая среда). Для ИС проектного бюро можно выделить следующие ключевые роли: Администратор, Руководитель проекта (Менеджер), Оператор (Исполнитель/Участник проекта).
   • Сценарии использования (Use Cases): Описание типичных последовательностей действий, которые пользователь будет выполнять в системе для достижения определенной цели. Например, сценарий «Руководитель проекта создает новый проект».
3. Определение функций приложения: На основе пользовательских профилей и сценариев формируется полный список функций, которые система должна предоставлять.
4. Разработка диаграммы вариантов использования UML: Графическое представление функциональных требований, показывающее, какие акторы (пользователи) взаимодействуют с какими вариантами использования (функциями) системы.

5.2 Функциональные требования для ролей пользователей (Администратор, Руководитель, Оператор)

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

Функциональные требования для Администратора:

Администратор является «хранителем» системы, обеспечивая её стабильность и безопасность.

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

Функциональные требования для Руководителя проекта:

Руководитель проекта — центральная фигура в управлении проектами, нуждающаяся в полном контроле и аналитике.

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

Функциональные требования для Оператора (Исполнителя):

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

• Просмотр назначенных задач: Доступ к списку задач, назначенных конкретному оператору, с возможностью просмотра их деталей (описание, сроки, приоритет, привязка к проекту).
• Обновление статуса выполнения задач: Изменение статуса задачи (например, «В работе», «Выполнено», «Отложено») и добавление комментариев, вложений.
• Учет рабочего времени: Ввод фактически затраченного времени на выполнение задач.
• Доступ к проектной документации: Просмотр файлов и документов, связанных с задачами и проектами.
• Взаимодействие с участниками проекта: Возможность отправки запросов или сообщений другим участникам проекта через систему.

5.3 Проектирование пользовательских интерфейсов

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

• Формы: Основной инструмент для ввода и просмотра данных.
  • Форма «Сведения о проекте»: Для ввода названия, описания, сроков, бюджета, назначения руководителя проекта. Включает поля для всех ключевых атрибутов проекта.
  • Форма «Сведения о сотруднике»: Для ввода личных данных, должности, контактной информации, доступности.
  • Форма «Управление задачами»: Для добавления, редактирования задач, назначения исполнителей, установки сроков и статусов.
  • Форма «Учет рабочего времени»: Для операторов, где они могут вводить часы, потраченные на конкретные задачи.

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

• Запросы: Используются для поиска и фильтрации данных по заданным критериям.
  • «Все активные проекты».
  • «Задачи, назначенные на меня».
  • «Проекты с просроченным сроком».
  • «Сотрудники, доступные для нового назначения».

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

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

6. Стандарты в проектировании информационных систем и баз данных

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

Ниже представлен обзор ключевых ГОСТов, которые рекомендуется использовать при проектировании ИС для проектного бюро:

• ГОСТ 34.321-96 «Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными»:
  

  Этот стандарт определяет эталонную модель управления данными, которая устанавливает общие принципы и терминологию для организации, хранения и доступа к данным в информационных системах. Руководство этим ГОСТом позволяет проектировать базы данных, соответствующие общепринятым архитектурным подходам, обеспечивая их структурированность и логичность.

• ГОСТ Р 43.0.11-2014 «Информационное обеспечение техники и операторской деятельности. Базы данных в технической деятельности»:
  

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

• ГОСТ 7.70-96 «СИБИД. Описание баз данных и машиночитаемых информационных массивов. Состав и обозначение характеристик»:
  

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

• ГОСТ Р ИСО/МЭК 25001-2017 «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Планирование и управление»:
  

  Идентичный международному стандарту ISO/IEC 25001:2014, этот ГОСТ является частью серии стандартов SQuaRE (System and Software Quality Requirements and Evaluation). Он предоставляет руководство по планированию и управлению требованиями и оценке качества систем и программного обеспечения. Следование этому стандарту позволяет систематизировать процесс сбора, анализа и управления требованиями к ИС, а также обеспечить адекватную оценку её качества на всех этапах жизненного цикла.

• ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов»:
  

  Хотя этот стандарт напрямую не касается проектирования ИС, он определяет состав реквизитов и правила оформления организационно-распорядительной документации, в том числе с применением информационных технологий. Для курсовой работы это означает, что вся сопроводительная документация (пояснительная записка, отчёты, руководства пользователя), создаваемая в рамках проекта, должна быть оформлена в соответствии с этим ГОСТом, что придаёт работе академическую строгость и профессиональный вид.

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

Заключение

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

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

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

Наконец, мы разработали детализированные функциональные требования для различных ролей пользователей (Администратор, Руководитель проекта, Оператор) и спроектировали интуитивно понятные пользовательские интерфейсы, что критически важно для эффективного взаимодействия с системой. Строгое следование национальным и международным стандартам, таким как ГОСТ 34.321-96, ГОСТ Р 43.0.11-2014, ГОСТ 7.70-96, ГОСТ Р ИСО/МЭК 25001-2017 и ГОСТ Р 7.0.97-2025, обеспечило академическую строгость и практическую ценность работы, подтверждая соответствие разработанного решения современным требованиям к качеству и документации.

Цели курсовой работы были полностью достигнуты. Разработанная ИС на базе MS Access представляет собой функциональное и методологически обоснованное решение для проектного бюро, способное значительно повысить эффективность его деятельности. Перспективы дальнейшего развития системы включают интеграцию с внешними сервисами, расширение функционала для поддержки более сложных аналитических отчетов и, при необходимости масштабирования, миграцию на более мощные серверные СУБД с сохранением логической структуры, заложенной на начальных этапах проектирования.

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

1. Информатика и информационные технологии. Учебное пособие / Под ред. Ю.Ю. Романова. Москва: ЭКСМО, 2005. 544 с. (Высшее экономическое образование).
2. Бугорский В.Н., Соколов Р.Е. Экономика и проектирование информационных систем. Санкт-Петербург: Питер, 1998. 340 с.
3. Введение в информационный бизнес / Под ред. В.П. Тихомирова, А.В. Хорошилова. Москва: Финансы и статистика, 1996. 239 с.
4. Вейскас Джон. Access 7.0 для Windows. Санкт-Петербург: Питер, 2003. 850 с.
5. Рик В. Microsoft Access 97: Справочник. Санкт-Петербург: Питер, 1999. 411 с.
6. Грабауров В.А. Информационные технологии для менеджеров. Москва: Финансы и статистика, 2001. 368 с.
7. Джонс Эдвард, Джонс Джарел. Access 97 Книга ответов. Санкт-Петербург: Питер, 1998. 390 с.
8. Зегжда Д.П., Ивашко А.М. Как построить защищенную систему. Санкт-Петербург: НПО “Мир и семья”, 1997. 290 с.
9. Карминский А.М., Нестеров П.В. Информатизация бизнеса. Москва: Финансы и статистика, 1997. 415 с.
10. Мельников В. Защита информации в компьютерных системах. Москва: Финансы и статистика, 1997. 364 с.
11. Морозов В.П., Тихомиров В.П., Хрусталев Е.Ю. Гипертексты в экономике. Информационная технология моделирования. Москва: Финансы и статистика, 1997. 253 с.
12. ГОСТ Р 7.0.97-2025. Национальный стандарт Российской Федерации. Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов. Утвержден Приказом Росстандарта от 26.06.2025 N 622-ст. Доступно по ссылке: https://www.klerk.ru/doc/713627/ (дата обращения: 28.10.2025).
13. ГОСТ Р ИСО/МЭК 25001-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Планирование и управление. Доступно по ссылке: https://docs.cntd.ru/document/1200146014 (дата обращения: 28.10.2025).
14. ГОСТ 34.321-96: Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными. Доступно по ссылке: https://star-pro.ru/gost-34-321-96/ (дата обращения: 28.10.2025).
15. ГОСТ Р 43.0.11-2014 Информационное обеспечение техники и операторской деятельности. Базы данных в технической деятельности. Доступно по ссылке: https://docs.cntd.ru/document/1200114092 (дата обращения: 28.10.2025).
16. В чем преимущества и недостатки Microsoft Access по сравнению с современными облачными решениями? Доступно по ссылке: https://spravochnick.ru/tehnologii/v-chem-preimuschestva-i-nedostatki-microsoft-access-po-sravneniyu-s-sovremennymi-oblachnymi-resheniyami/ (дата обращения: 28.10.2025).
17. Методологии проектирования информационных систем. Доступно по ссылке: https://studfile.net/preview/4414168/page:5/ (дата обращения: 28.10.2025).
18. Основные понятия и краткая характеристика Microsoft Access. Доступно по ссылке: https://studfile.net/preview/1039019/page:3/ (дата обращения: 28.10.2025).
19. Структурный подход к проектированию информационной системы. Функциональная модель АСОИУ. Количественный анализ диаграмм IDEF0 и DFD. Доступно по ссылке: https://studfile.net/preview/3638202/page:3/ (дата обращения: 28.10.2025).
20. Сравнительный анализ подходов к проектированию ИС. Доступно по ссылке: https://studfile.net/preview/716182/page:7/ (дата обращения: 28.10.2025).
21. Нормализация базы данных. Доступно по ссылке: https://studfile.net/preview/3931668/page:10/ (дата обращения: 28.10.2025).
22. Практическая работа 40 Создание ER-диаграмм. Доступно по ссылке: https://studfile.net/preview/6636730/page:2/ (дата обращения: 28.10.2025).
23. Что такое ER-диаграмма и как ее создать? Доступно по ссылке: https://www.lucidchart.com/pages/ru/chto-takoe-er-diagramma-i-kak-ee-sozdat (дата обращения: 28.10.2025).
24. Значение и возможности БД MS Access. Доступно по ссылке: https://studfile.net/preview/5587754/page:4/ (дата обращения: 28.10.2025).
25. Структурный подход к проектированию ИС. Доступно по ссылке: https://moodle.enu.kz/pluginfile.php/127163/mod_resource/content/1/Lecture%203.pdf (дата обращения: 28.10.2025).
26. ER-диаграммы: как создать, примеры построения модели. Доступно по ссылке: https://journal.tinkoff.ru/er-diagram/ (дата обращения: 28.10.2025).
27. Инфологическая модель данных «Сущность-связь». Доступно по ссылке: https://studfile.net/preview/3588722/page:7/ (дата обращения: 28.10.2025).
28. Методы проектирования информационных систем. Доступно по ссылке: https://cyberleninka.ru/article/n/metody-proektirovaniya-informatsionnyh-sistem (дата обращения: 28.10.2025).
29. ER диаграмма управления проектами. Доступно по ссылке: https://creately.com/ru/examples/erd/project-management-er-diagram/ (дата обращения: 28.10.2025).
30. ER-диаграмма: что это, применение, нотации — как создать ER-диаграмму сущность-связь, примеры. Доступно по ссылке: https://practicum.yandex.ru/blog/er-diagramma/ (дата обращения: 28.10.2025).
31. Лекция 7: Инфологическое моделирование. Доступно по ссылке: https://www.intuit.ru/studies/courses/2/2/lecture/40 (дата обращения: 28.10.2025).
32. 5 причин, по которым малому бизнесу следует выбрать MS Access. Доступно по ссылке: https://www.datanumen.com/ru/blogs/5-reasons-small-businesses-should-opt-for-ms-access.htm (дата обращения: 28.10.2025).
33. Проектирование баз данных — ПИ-09-03. Доступно по ссылке: https://www.sgu.ru/sites/default/files/textdocs/2017-10-27/2.1_proektirovanie_baz_dannyh.pdf (дата обращения: 28.10.2025).
34. Практическая работа № 2 Проектирование инфологической модели методом «Сущность-связь»: методические материалы на Инфоурок. Доступно по ссылке: https://infourok.ru/prakticheskaya-rabota-proektirovanie-infologicheskoy-modeli-metodom-suschnostsvyaz-5712128.html (дата обращения: 28.10.2025).
35. Занятие 4. Нормализация базы данных. Доступно по ссылке: https://mymanual.ru/microsoft-access-2003/zanyatie-4-normalizatsiya-bazy-dannykh/ (дата обращения: 28.10.2025).
36. Инфологическая модель данных: пример построения ER-диаграммы. Доступно по ссылке: https://www.rae.ru/forum2012/222/2361 (дата обращения: 28.10.2025).
37. База данных access. Как создать. Козлов Алексей Олегович. РУНО. Доступно по ссылке: https://www.youtube.com/watch?v=F_f-M-uG5Gk (дата обращения: 28.10.2025).
38. Нормальные формы баз данных: Объясняем на пальцах. Доступно по ссылке: https://www.youtube.com/watch?v=tNQlFW3BRUc (дата обращения: 28.10.2025).
39. Все преимущества и недостатки программы обеспечения информационной безопасности. Доступно по ссылке: https://staffcop.ru/blog/vse-preimushchestva-i-nedostatki-programmy-obespecheniya-informatsionnoy-bezopasnosti/ (дата обращения: 28.10.2025).
40. Реляционные базы данных. Создание базы данных в Access. Доступно по ссылке: https://www.youtube.com/watch?v=t-V5_K29KGE (дата обращения: 28.10.2025).
41. Реляционная модель данных, ER диаграмма. Базы данных. Доступно по ссылке: https://www.youtube.com/watch?v=d_pX3P3b5Q0 (дата обращения: 28.10.2025).
42. Примеры и принципы нормализации реляционных баз данных (БД). Доступно по ссылке: https://decosystems.ru/blog/normalization-of-relational-databases/ (дата обращения: 28.10.2025).
43. Спецификации Access. Служба поддержки Майкрософт. Доступно по ссылке: https://support.microsoft.com/ru-ru/office/%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B8-access-0f72782b-6d33-4632-9b98-0cf2d93e8cc1 (дата обращения: 28.10.2025).
44. Безопасность в Access 2010. Служба поддержки Майкрософт. Доступно по ссылке: https://support.microsoft.com/ru-ru/office/%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D0%B2-access-2010-388126b8-2a1e-4537-8b01-38e53995f519 (дата обращения: 28.10.2025).
45. Проектирование реляционных баз данных. Доступно по ссылке: https://miem.hse.ru/data/2013/05/20/1286311654/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%20%D1%80%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D1%85%20%D0%B1%D0%B0%D0%B7%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85.pdf (дата обращения: 28.10.2025).
46. С 1 ноября начнут действовать новые ГОСТы в сфере строительства, производства СИЗ и пожарной защиты. Доступно по ссылке: https://ru-bezh.ru/news/2025-10-27/s-1-noyabrya-nachnut-deystvovat-novye-gosty-v-sfere-stroitelstva-proizvodstva-siz-i-pozharnoy-zashchity (дата обращения: 28.10.2025).
47. ER-диаграммы для бизнес-аналитиков. Доступно по ссылке: https://www.youtube.com/watch?v=D-gYc33-Mv4 (дата обращения: 28.10.2025).
48. Лекция 1. Введение в проектирование баз данных. Доступно по ссылке: https://msuniversity.ru/courses/base/lectures/lecture_1 (дата обращения: 28.10.2025).
49. Стандарт. Википедия. Доступно по ссылке: https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82 (дата обращения: 28.10.2025).
50. Об автоматизации в BPM-системах. Перед проектированием процесса. Доступно по ссылке: https://rabota.dev/posts/ob-avtomatizatsii-v-bpm-sistemakh-pered-proektirovaniem-protsessa/ (дата обращения: 28.10.2025).
51. Инфологическое проектирование базы данных. Доступно по ссылке: https://studfile.net/preview/6636730/page:8/ (дата обращения: 28.10.2025).
52. Проектируем объекты ж/д транспорта: требования действующих законодательных актов и технических регламентов. Доступно по ссылке: https://gge.ru/press-center/news/proektiruem-obekty-zh-d-transporta-trebovaniya-deystvuyushchikh-zakonodatelnykh-aktov-i-tekhnicheskikh-reglamentov/ (дата обращения: 28.10.2025).
53. Проектирование баз данных. Метод ER-диаграмм. Основы программирования и базы данных — online presentation — ppt Online. Доступно по ссылке: https://ppt-online.org/472449 (дата обращения: 28.10.2025).
54. БД и СУБД. Доступно по ссылке: https://comp-science.ru/bd-i-subd.html (дата обращения: 28.10.2025).
55. Курс «Системный аналитик». Урок 10: Данные, ER-диаграмма. Доступно по ссылке: https://www.youtube.com/watch?v=3n-v99bYJ_E (дата обращения: 28.10.2025).
56. 10 систем управления проектами с AI: проверила, где искусственный интеллект работает без менеджеров. Доступно по ссылке: https://habr.com/ru/articles/861757/ (дата обращения: 28.10.2025).
57. Платформа BPMSoft. Управление маркетингом, продажами и сервисом. Конструктор low-code. Доступно по ссылке: https://bpmonline.com/ (дата обращения: 28.10.2025).
58. Быстро запуститься, выжить и преуспеть: как предпринимателю выйти на маркетплейсы. Доступно по ссылке: https://www.retail.ru/articles/bystro-zapustitsya-vyzhit-i-preuspet-kak-predprinimatelyu-vyyti-na-marketpleysy/ (дата обращения: 28.10.2025).
59. «Группа Астра» лидер российского рынка информационных технологий в области разработки программного обеспечения (ПО) и средств защиты информации. Доступно по ссылке: https://astralinux.ru/company/ (дата обращения: 28.10.2025).
60. Использование шаблона базы данных Projects Access. Microsoft Support. Доступно по ссылке: https://support.microsoft.com/ru-ru/office/%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D0%B0-%D0%B1%D0%B0%D0%B7%D1%8B-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-projects-access-5bb6e13e-1b8f-4375-9659-19d4530062a4 (дата обращения: 28.10.2025).
61. Использование Access для управления проектами : r/MSAccess. Доступно по ссылке: https://www.reddit.com/r/MSAccess/comments/1c31h4p/using_access_to_manage_projects/ (дата обращения: 28.10.2025).
62. Информационные системы по управлению задачами: преимущества для бизнеса. Доступно по ссылке: https://advanta-group.ru/blog/informacionnye-sistemy-upravleniya-zadachami/ (дата обращения: 28.10.2025).
63. Что такое функциональные требования: примеры и шаблоны. Доступно по ссылке: https://visuresolutions.com/ru/what-are-functional-requirements/ (дата обращения: 28.10.2025).
64. Access: что такое и как это работает — Узнайте все о доступе к информации. Доступно по ссылке: https://skyeng.ru/articles/chto-takoe-microsoft-access-i-kak-eto-rabotaet/ (дата обращения: 28.10.2025).
65. Разработка функциональных требований к информационной системе «ООО — Уральский федеральный университет. Доступно по ссылке: https://elar.urfu.ru/bitstream/10995/82155/1/m_d_fatakhov_2020.pdf (дата обращения: 28.10.2025).
66. Система управления проектами: составляющие и правила выбора. Доступно по ссылке: https://gb.ru/blog/sistema-upravleniya-proektami/ (дата обращения: 28.10.2025).
67. Информационная система управления проектами — Экономическая библиотека онлайн. Доступно по ссылке: https://economy-lib.com/informatsionnaya-sistema-upravleniya-proektami (дата обращения: 28.10.2025).
68. Что такое ER-диаграмма (drow.io) — простыми словами. Доступно по ссылке: https://www.youtube.com/watch?v=F01y0m75T40 (дата обращения: 28.10.2025).
69. Объясняю что такое ER диаграммы SQL на простейшем примере «для чайников». Доступно по ссылке: https://www.youtube.com/watch?v=8V3-L16sT8U (дата обращения: 28.10.2025).
70. Лабораторная работа №5 создание ER-диаграммы в Drow.io (https://app.diagrams.net). Доступно по ссылке: https://www.youtube.com/watch?v=9_d8zF5wY2o (дата обращения: 28.10.2025).
71. Как просто создать диаграмму сущностей ERD? (ER-диаграммы drow.io). Доступно по ссылке: https://www.youtube.com/watch?v=0k5Gj6fB80w (дата обращения: 28.10.2025).
72. Системы автоматизации: как максимально автоматизировать бизнес-процессы. Доступно по ссылке: https://bafsys.ru/articles/sistemy-avtomatizatsii-kak-maksimalno-avtomatizirovat-biznes-protsessy/ (дата обращения: 28.10.2025).
73. Как внедрять genAI в бизнес так, чтобы видеть результат в P&L. Доступно по ссылке: https://habr.com/ru/companies/mailru/articles/861461/ (дата обращения: 28.10.2025).
74. С чего начать автоматизацию процессов: ключевые принципы. Доступно по ссылке: https://www.youtube.com/watch?v=p4vWc6M7-0c (дата обращения: 28.10.2025).
75. CRM-система для создания и автоматизации бизнес-процессов компании — OkoCRM. Доступно по ссылке: https://okocrm.com/avtomatizatsiya-biznes-processov/ (дата обращения: 28.10.2025).
76. NAUMEN — информационные системы управления растущим бизнесом. Доступно по ссылке: https://www.naumen.ru/ (дата обращения: 28.10.2025).
77. Разработка интерфейса и стиля для системы управления проектами. Доступно по ссылке: https://jetstyle.ru/cases/razrabotka-interfeysa-i-stilya-dlya-sistemy-upravleniya-proektami (дата обращения: 28.10.2025).
78. Проектирование интерфейсов пользователя. Электронная библиотека БГТУ. Доступно по ссылке: https://www.bstu.by/static/docs/library/posobiya/21.05.2020/brusencova_proektirovanie_interfejsov_polzovatelya.pdf (дата обращения: 28.10.2025).
79. Состав разделов проектной документации на объекты капитального строительства производственного и непроизводственного назначения и требования к содержанию этих разделов. КонсультантПлюс. Доступно по ссылке: https://www.consultant.ru/document/cons_doc_LAW_107936/2ddbbf178d3864454848348d4889c0490f845a76/ (дата обращения: 28.10.2025).
80. Применение системного анализа при разработке пользовательского интерфейса информационных систем. Доступно по ссылке: https://www.elibrary.ru/download/elibrary_43038612_82837330.pdf (дата обращения: 28.10.2025).
81. Типы организационных структур. Доступно по ссылке: https://www.youtube.com/watch?v=0-tD-Gk13cQ (дата обращения: 28.10.2025).
82. Управление проектами. Виды организационных структур. Доступно по ссылке: https://www.youtube.com/watch?v=RkL37Wz9hJ8 (дата обращения: 28.10.2025).
83. Организационная структура проектного управления. Доступно по ссылке: https://www.youtube.com/watch?v=H74aMjj5N4M (дата обращения: 28.10.2025).