Проектирование и Реализация Информационной Системы для Проектного НИИ: От Анализа до Внедрения и Тестирования

Современный мир невозможно представить без информационных систем. Они стали не просто инструментом, а кровеносной системой любой организации, позволяющей не только обрабатывать, но и стратегически управлять потоками данных. За последний год российские компании инвестировали в цифровизацию колоссальные 5,24 трлн рублей, что является впечатляющим ростом на 29,5% по сравнению с предыдущим периодом. Более того, 42% компаний уже планируют увеличить свои инвестиции в IT-инфраструктуру в 2025 году, с акцентом на повышение отказоустойчивости и надежности систем. Эти цифры красноречиво говорят о том, что информационные системы перестали быть просто дополнением, превратившись в критически важный фактор конкурентоспособности и эффективности.

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

Основы Информационных Систем и Баз Данных

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

Понятие и Компоненты Информационной Системы

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

• Данные: Сырой материал, факты, цифры, текстовая информация, которая собирается, хранится и обрабатывается.
• Техническое обеспечение: Физические устройства, составляющие инфраструктуру системы. Сюда относятся компьютеры любых моделей, серверы, устройства сбора (сканеры, датчики), накопления (жесткие диски, твердотельные накопители), обработки (процессоры), передачи (сетевое оборудование, линии связи) и вывода информации (принтеры, мониторы), а также оргтехника и устройства автоматического съема информации. Например, для "Проектного НИИ" это могут быть мощные серверы для хранения результатов исследований и специализированные рабочие станции для аналитиков.
• Программное обеспечение: Набор инструкций, управляющих аппаратными средствами и обеспечивающих выполнение задач. Оно делится на:
  • Общесистемное ПО: Фундамент, на котором работает вся система (операционные системы, драйверы, программы управления файлами). Яркие представители — Linux и Windows.
  • Специальное (прикладное) ПО: Программы, предназначенные для решения конкретных задач (текстовые редакторы, табличные процессоры, СУБД, ERP-, CRM-системы). В российском контексте можно выделить такие решения, как Naumen Service Desk для управления IT-услугами и Jinn-Server для защиты информационных систем. Для НИИ это могут быть специализированные системы управления проектами, научными публикациями или лабораторным оборудованием.
• Персонал: Люди, которые взаимодействуют с системой – конечные пользователи, администраторы, разработчики.
• Организационное обеспечение: Методологии, инструкции, регламенты и политики, определяющие, как система должна использоваться и управляться.

Сущность и Типы Баз Данных

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

Исторически доминирующей моделью стала реляционная база данных (РБД), сформулированная Э. Ф. Коддом в 1969-1970 годах. В её основе лежит математическая теория множеств и логика первого порядка, где данные представляются в виде набора двумерных таблиц (отношений). Каждая строка в такой таблице представляет собой отдельную запись (кортеж), а каждый столбец — атрибут. Взаимосвязи между таблицами устанавливаются через общие поля (ключи), что обеспечивает целостность данных и позволяет использовать мощный аппарат реляционной алгебры для манипуляций с информацией. Пример реляционной модели в НИИ — это таблицы для проектов, сотрудников, публикаций, грантов, связанных между собой уникальными идентификаторами.

Однако, с ростом объемов и разнообразия данных, а также необходимостью масштабирования, появились альтернативные подходы. Здесь мы углубимся в "слепую зону" традиционных курсовых работ: нереляционные (NoSQL) базы данных и NewSQL базы данных.

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

• Документоориентированные БД (например, MongoDB): Хранят данные в виде полуструктурированных документов (часто JSON или BSON), что удобно для хранения разнородных данных, таких как метаданные исследований или неструктурированные отчеты.
• Хранилища «ключ-значение» (например, Redis, Amazon DynamoDB): Простейшая модель, где каждый элемент данных представляет собой пару «ключ – значение». Идеально подходят для кэширования, управления сессиями и хранения пользовательских настроек в НИИ.
• Колоночные БД (например, Google BigTable, Apache Cassandra): Организуют данные по столбцам, а не по строкам, что обеспечивает высокую производительность при аналитических запросах, затрагивающих определенные столбцы. Могут быть полезны для агрегирования статистических данных по проектам.
• Графовые БД (например, Neo4j): Хранят данные в виде узлов (сущностей) и рёбер (связей), что оптимально для представления сложных взаимосвязей между научными проектами, исследовательскими группами, публикациями и грантами, позволяя легко находить неочевидные связи.

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

Выбор типа базы данных для "Проектного НИИ" будет зависеть от специфики хранимых данных, требований к производительности, масштабируемости и гибкости. Реляционная модель будет основой для структурированных данных (проекты, сотрудники, публикации), в то время как NoSQL решения могут дополнить её для работы с неструктурированными данными или для высоконагруженных аналитических задач.

Процессы в Информационных Системах

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

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

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

Жизненный Цикл Программного Обеспечения и Анализ Требований для НИИ

Программное обеспечение, подобно живому организму, проходит через определенные этапы развития — от зарождения идеи до прекращения поддержки. Этот путь описывается концепцией Жизненного Цикла Программного Обеспечения (ЖЦ ПО или SDLC). Понимание SDLC критически важно для любого IT-проекта, поскольку оно задает структуру, методологию и последовательность действий, необходимых для создания качественного и соответствующего требованиям продукта.

Модели Жизненного Цикла ПО

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

• Каскадная модель (Waterfall): Самый традиционный и линейный подход. Каждый этап (сбор и анализ требований, проектирование, разработка, тестирование, внедрение) выполняется строго последовательно, и переход к следующему этапу возможен только после полного завершения предыдущего. Эта модель подходит для проектов с четко определенными, стабильными требованиями, где изменения маловероятны. Её простота в управлении и документации является преимуществом, но негибкость и позднее обнаружение ошибок — существенным недостатком.
• Инкрементная модель: Разработка ведется итерациями, где каждый последующий инкремент добавляет новую функциональность, что позволяет быстрее получить базовый продукт и постепенно его улучшать.
• Спиральная модель: Объединяет элементы каскадной и итеративной моделей, добавляя акцент на управление рисками. Каждый виток спирали включает планирование, анализ рисков, проектирование, разработку и оценку. Идеально для крупных, сложных проектов с высоким уровнем неопределенности.
• V-образная модель: Расширенная версия каскадной модели, которая предусматривает параллельное развитие этапов разработки и тестирования. Например, на этапе анализа требований разрабатываются приемочные тесты, на этапе проектирования — системные, на этапе модульной разработки — модульные. Это позволяет обнаруживать дефекты значительно раньше.
• Итеративная модель: Повторяющиеся циклы разработки, в каждом из которых создается небольшая часть функционала. Продукт постоянно уточняется и улучшается.

Гибкие методологии (Agile, Scrum) — это ключевая "слепая зона", которую мы восполняем. В отличие от строгих последовательных моделей, Agile-подходы акцентируют внимание на постоянной коммуникации, сотрудничестве с заказчиком и быстрой адаптации к изменениям. Разработка разбивается на короткие циклы, называемые спринтами (обычно 1-4 недели), в конце каждого из которых команда представляет работающий инкремент продукта. Scrum — это один из наиболее популярных фреймворков Agile, включающий роли (владелец продукта, скрам-мастер, команда разработки), артефакты (бэклог продукта, бэклог спринта) и события (планирование спринта, ежедневные скрамы, обзор спринта, ретроспектива). Для "Проектного НИИ", где требования могут эволюционировать по мере развития исследований, Agile-подходы обеспечивают необходимую гибкость и позволяют оперативно реагировать на меняющиеся потребности.

Этап Анализа Требований: Особенности для Проектного НИИ

Этап анализа требований — это фундамент всего проекта, его наиболее критически важный этап. Именно здесь формируются цели, ставятся задачи, проясняются условия, сроки и бюджет. Стоимость исправления ошибки, обнаруженной на этом этапе, минимальна — практически мгновенна, тогда как после вывода продукта на рынок она может быть в 30-100 раз выше. Проблемы с требованиями (недостаток коммуникации, нечеткое деление ролей) являются одними из главных причин неудач проектов. Какой важный нюанс здесь упускается? Часто недооценивается вклад конечных пользователей в формирование требований, а ведь именно их ежедневные потребности определяют реальную ценность будущей системы.

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

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

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

Этапы Проектирования и Разработки

После глубокого анализа требований наступает фаза реализации, которая традиционно делится на проектирование и разработку.

На этапе проектирования определяется "скелет" и "нервная система" будущей системы:

• Архитектура приложения: Разработка высокоуровневой структуры системы (например, клиент-сервер, многоуровневая архитектура).
• Функции системы: Детализация функциональных блоков и их взаимодействия.
• Требования к интерфейсу: Проектирование пользовательского интерфейса (UI) и пользовательского опыта (UX) — макеты, прототипы, навигационная структура.
• Выбор СУБД и варианта хранения данных: Обоснованный выбор между реляционными, нереляционными или NewSQL базами данных в зависимости от потребностей.
• Проектирование базы данных: Создание логической и физической модели БД, определение таблиц, полей, связей, индексов.
• Проектирование алгоритмов: Разработка детальных алгоритмов для обработки данных и реализации бизнес-логики.

Этап разработки продукта — это процесс воплощения проектных решений в реальный код:

• Написание кода: Программирование функционала системы на выбранных языках и фреймворках.
• Создание базы данных: Физическое развертывание БД, создание таблиц, индексов, хранимых процедур.
• Интеграция сервисов: Подключение сторонних библиотек, API, других систем, если это предусмотрено архитектурой.
• Модульное тестирование: Проверка корректности работы отдельных компонентов кода.

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

Проектирование Базы Данных: От Моделирования до Нормализации

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

Реляционная Модель Данных

В основе подавляющего большинства современных баз данных лежит реляционная модель данных (РМД). Эта прикладная теория, разработанная Э. Ф. Коддом в 1969–1970 годах, является краеугольным камнем проектирования структурированных хранилищ информации. РМД опирается на строгие математические концепции из теории множеств и логики первого порядка.

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

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

ER-Модель и ER-Диаграммы

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

Ключевыми элементами ER-модели являются:

• Сущности: Это объекты реального мира или концепции, информация о которых должна быть отражена в базе данных. В контексте "Проектного НИИ" сущностями могут быть "Проект", "Сотрудник", "Грант", "Публикация", "Оборудование".
• Атрибуты: Это свойства или характеристики сущности. Например, для сущности "Проект" атрибутами будут "Название", "Дата начала", "Статус", "Бюджет". Для сущности "Сотрудник" — "ФИО", "Должность", "Ученая степень". Атрибуты обычно соответствуют столбцам в будущей таблице БД.
• Связи: Отношения между сущностями. Например, "Сотрудник участвует в Проекте", "Проект финансируется за счет Гранта", "Сотрудник публикует Публикацию". Связи могут быть различных типов:
  • Один к одному (1:1): Например, "Проект имеет Одного руководителя".
  • Один ко многим (1:M): Например, "Один руководитель может управлять Многими проектами".
  • Многие ко многим (M:N): Например, "Многие сотрудники участвуют в Многих проектах".

ER-диаграмма (ERD) — это графическое представление ER-модели, разновидность блок-схемы, наглядно показывающая, как сущности связаны между собой. Для проектирования БД "Проектного НИИ" ERD станет ключевым инструментом. Мы можем изобразить сущность "Проект" (прямоугольник), её атрибуты ("Название", "Бюджет", "Статус") и связать её с сущностью "Сотрудник" (прямоугольник с атрибутами "ФИО", "Должность") через связь "Руководит" (ромб), указав тип связи "Один ко многим", где один сотрудник может руководить множеством проектов, но каждый проект имеет одного руководителя.

Нормализация Базы Данных

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

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

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

Применение нормализации для проектирования БД "Проектного НИИ" позволит избежать таких проблем, как дублирование информации (например, многократное хранение названия гранта для каждого проекта, им финансируемого), противоречивость данных (изменение названия гранта в одном месте, но не в другом) и аномалии при модификации данных. Это обеспечит высокую степень целостности и эффективность работы с данными, что критически важно для надежного управления научными проектами.

Архитектура Системы и Технологии Реализации

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

Выбор Архитектурных Решений

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

1. Клиент-серверная архитектура: Это базовый паттерн, где клиенты (пользовательские устройства, браузеры) запрашивают ресурсы или сервисы у серверов.
   • Преимущества: Централизованное управление данными и безопасностью, упрощение резервного копирования.
   • Недостатки: Сервер может стать "узким местом", зависимость клиента от сервера.
   • Актуальность для НИИ: Подходит для большинства базовых функций, где пользователи напрямую взаимодействуют с центральной базой данных через приложение.
2. Трехзвенная (многоуровневая) архитектура: Развитие клиент-серверной модели, где логика приложения разделена на три основных слоя:
   • Уровень представления (Presentation Layer): Пользовательский интерфейс, с которым взаимодействует конечный пользователь (например, веб-браузер, десктопное приложение).
   • Уровень бизнес-логики (Application Layer): Серверный компонент, содержащий основную логику приложения, обрабатывающий запросы от уровня представления и взаимодействующий с уровнем данных.
   • Уровень данных (Data Layer): База данных и механизмы доступа к ней, отвечающие за хранение и извлечение информации.
   • Преимущества: Высокая масштабируемость (каждый уровень может масштабироваться независимо), улучшенная безопасность (уровень данных изолирован от клиента), гибкость в изменении технологий на каждом уровне, упрощение поддержки и развития.
   • Недостатки: Большая сложность в разработке и развертывании по сравнению с двухуровневой.
   • Актуальность для НИИ: Наиболее целесообразный подход для "Проектного НИИ". Он позволяет обрабатывать сложные бизнес-процессы, связанные с управлением грантами и исследованиями, обеспечивает возможность интеграции с другими научными системами и позволяет легко адаптировать систему к меняющимся требованиям без полной перестройки. Например, можно отдельно масштабировать серверы приложений для обработки большего количества одновременных пользователей или заменить СУБД без влияния на клиентскую часть.

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

Технологический Стек для Реализации

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

Для "Проектного НИИ" может быть рекомендован следующий технологический стек:

• Система управления базами данных (СУБД):
  • Основная реляционная СУБД: PostgreSQL или Oracle Database. PostgreSQL является мощной, открытой и надежной СУБД с широким функционалом, подходящей для хранения структурированных данных о проектах, сотрудниках, грантах. Oracle Enterprise Database — промышленный стандарт, обеспечивающий высочайшую производительность, безопасность и масштабируемость, но требующий лицензионных отчислений. Выбор будет зависеть от бюджета и критичности данных.
  • Возможное дополнение (NoSQL для специфических задач): MongoDB для хранения неструктурированных данных, таких как текстовые аннотации исследований, сканы документов, или Neo4j для моделирования сложных связей между публикациями, авторами и исследовательскими направлениями.
  • Обоснование: PostgreSQL предлагает высокую надежность и расширяемость, а также отличную поддержку для геопространственных данных, что может быть полезно для проектов, связанных с картографией или геологией. Oracle — лидер рынка с проверенными решениями для корпоративного уровня. Интеграция NoSQL позволит гибко работать с разнородными данными, не перегружая реляционную модель.
• Язык программирования для Backend (Уровень бизнес-логики):
  • Python (с фреймворками Django/Flask) или Java (с фреймворками Spring/Spring Boot).
  • Обоснование: Python с Django/Flask обеспечивает быструю разработку, читаемый код и обширную экосистему библиотек, включая инструменты для анализа данных и машинного обучения, что может быть ценно для НИИ. Java со Spring Boot — это проверенное решение для построения высоконагруженных, корпоративных приложений с акцентом на стабильность и производительность. Оба варианта поддерживают RESTful API, что критично для взаимодействия с frontend.
• Язык программирования/Фреймворк для Frontend (Уровень представления):
  • JavaScript (с фреймворками React.js / Vue.js / Angular).
  • Обоснование: Эти фреймворки позволяют создавать современные, интерактивные и отзывчивые пользовательские интерфейсы. React.js и Vue.js известны своей производительностью и гибкостью, Angular — структурированностью и поддержкой крупных корпоративных приложений. Выбор зависит от предпочтений команды и специфики UI.
• Контейнеризация и оркестрация (для развертывания):
  • Docker для упаковки приложения и его зависимостей в легко переносимые контейнеры.
  • Kubernetes для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями.
  • Обоснование: Обеспечивает высокую переносимость, упрощает развертывание в различных средах (локальный сервер НИИ, облако) и повышает отказоустойчивость системы.
• Система контроля версий: Git (с использованием GitHub/GitLab/Bitbucket) для эффективной командной разработки и отслеживания изменений в коде.

Реализация Пользовательского Интерфейса и Алгоритмов

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

Пользовательский интерфейс (UI) и пользовательский опыт (UX):
Проектирование интерфейса должно быть ориентировано на интуитивность и минимальное количество шагов для выполнения типовых операций. Для НИИ это означает:

• Лаконичный дашборд: Стартовая страница, представляющая ключевые метрики и актуальный статус проектов, грантов, задач, публикаций в виде графиков и виджетов.
• Эргономичные формы ввода: Продуманные формы для добавления новых проектов, сотрудников, грантов, минимизирующие ошибки ввода. Например, использование выпадающих списков для выбора статусов или типов проектов.
• Эффективные фильтры и поиск: Возможность быстро найти нужную информацию по проектам, публикациям, сотрудникам с помощью развитых фильтров и полнотекстового поиска.
• Наглядная визуализация: Использование диаграмм Ганта для планирования проектов, круговых диаграмм для распределения бюджетов, графиков для отслеживания прогресса.
• Адаптивный дизайн: Интерфейс должен корректно отображаться на различных устройствах (десктоп, планшет), поскольку научные сотрудники могут работать как в лаборатории, так и в пути.

Примеры скриншотов или макетов интерфейса:

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

Ключевые алгоритмы обработки данных, специфичные для управления проектами в НИИ:

1. Алгоритм расчета прогресса проекта:
   • Исходные данные: Список задач проекта, их трудоемкость (или вес), статус выполнения (не начато, в работе, завершено).
   • Формула:

   Прогресспроекта = ( Σi=1N (Весзадачи i × Процент выполнениязадачи i) ) / Σi=1N Весзадачи i

   • Пошаговое применение: Для каждой задачи определяется её вес (например, в часах или долях общего объема) и текущий процент выполнения. Затем суммируются произведения веса на процент выполнения для всех задач и делится на общую сумму весов.
   • Пример: Проект А имеет 3 задачи. Задача 1: вес 20, выполнена на 100%. Задача 2: вес 30, выполнена на 50%. Задача 3: вес 50, выполнена на 0%.
     Прогресс = ((20*100%) + (30*50%) + (50*0%)) / (20+30+50) = (20 + 15 + 0) / 100 = 35/100 = 35%.
2. Алгоритм генерации финансовых отчетов по грантам:
   • Исходные данные: Данные о грантах (сумма, даты), данные о расходах по статьям (дата, сумма, статья, привязка к гранту).
   • Логика: Агрегирование расходов за выбранный период по каждому гранту, сравнение с утвержденным бюджетом гранта, расчет остатка средств. Возможность фильтрации по статьям расходов.
3. Алгоритм управления доступом (Role-Based Access Control — RBAC):
   • Исходные данные: Пользователи, роли (например, "Руководитель проекта", "Научный сотрудник", "Бухгалтер", "Администратор"), права доступа к объектам системы (например, "Проект", "Грант", "Публикация") и действиям (создать, читать, обновить, удалить).
   • Логика: Каждый пользователь ассоциируется с одной или несколькими ролями. Каждая роль имеет предопределенный набор прав. При попытке пользователя выполнить действие, система проверяет, есть ли у его ролей необходимые права для этого действия над данным объектом.
4. Алгоритм поиска публикаций по ключевым словам и авторам:
   • Исходные данные: Тексты публикаций, метаданные (авторы, ключевые слова, дата).
   • Логика: Использование полнотекстового индексирования (встроенного в СУБД или внешних решений типа Elasticsearch) для быстрого поиска по тексту. Поиск по авторам осуществляется через связи с таблицей сотрудников.

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

Тестирование и Оценка Работоспособности Информационной Системы

Разработка информационной системы, какой бы продуманной она ни была, не может считаться завершенной без всестороннего тестирования. Тестирование ПО — это не просто поиск ошибок; это комплексная проверка соответствия между реальным и ожидаемым поведением программы, проводимая на наборе тестов. Главная цель — обнаружение дефектов, подтверждение качества ИТ-продукта и обеспечение его соответствия заданным требованиям. Особенно в контексте "Проектного НИИ", где ошибки могут привести к некорректному учету грантов или потере важных исследовательских данных, надежность системы критически важна.

Виды Тестирования ПО

Для обеспечения всесторонней проверки работоспособности системы применяется широкий спектр видов тестирования:

1. Модульное тестирование (Unit Testing):
   • Сущность: Проверка отдельных, наименьших логических частей (модулей, функций, классов) кода в изоляции от других компонентов.
   • Применение для НИИ: Например, проверка корректности алгоритма расчета прогресса проекта или функции добавления нового гранта. Это первый уровень тестирования, выполняемый разработчиками.
2. Интеграционное тестирование (Integration Testing):
   • Сущность: Выявление дефектов во взаимодействии между интегрированными элементами, модулями, уровнями или базами данных. Проверяется, как различные части системы работают вместе.
   • Применение для НИИ: Проверка взаимодействия между модулем управления проектами и модулем учета сотрудников, или между интерфейсом пользователя и базой данных при сохранении информации о публикации.
3. Функциональное тестирование (Functional Testing):
   • Сущность: Проверка корректности работы функциональности приложения на основе анализа спецификации. Отвечает на вопрос: "Делает ли система то, что должна делать?"
   • Применение для НИИ: Проверка, что система позволяет создать проект, привязать к нему сотрудника, сохранить отчет о гранте, корректно сгенерировать список публикаций по автору.
4. Системное тестирование (System Testing):
   • Сущность: Комплексная проверка системы в целом, как функциональных, так и нефункциональных требований, в условиях, приближенных к реальной эксплуатации.
   • Применение для НИИ: Полная проверка всего цикла управления проектом, от создания до завершения, включая генерацию отчетов и управление доступом, имитируя работу реальных пользователей НИИ.
5. Приемочное тестирование (Acceptance Testing):
   • Сущность: Выполняется заказчиком или конечными пользователями для подтверждения соответствия системы их ожиданиям и требованиям. Это финальный этап, после которого продукт может быть принят в эксплуатацию.
   • Применение для НИИ: Руководители проектов, администраторы, бухгалтеры НИИ проверяют, что система соответствует их бизнес-процессам и удобна в использовании.

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

• Нагрузочное тестирование (Load Testing): Проверка работы системы при ожидаемой пиковой нагрузке (например, одновременная работа 50-100 сотрудников НИИ).
• Стрессовое тестирование (Stress Testing): Проверка поведения системы при экстремальных нагрузках, значительно превышающих ожидаемые, для определения точки отказа и способности к восстановлению.
• Тестирование стабильности/надежности (Stability/Reliability Testing): Оценка работы системы в течение длительного времени при постоянной нагрузке, для выявления утечек памяти, зависаний.
• Тестирование безопасности (Security Testing): Выявление уязвимостей и проверка защищенности данных (например, от несанкционированного доступа к данным о грантах или конфиденциальным исследованиям).
• Тестирование пользовательского интерфейса (UI Testing): Проверка корректности отображения всех элементов интерфейса, их доступности и взаимодействия.
• Конфигурационное тестирование (Configuration Testing): Проверка работы системы в различных программно-аппаратных конфигурациях (разные браузеры, операционные системы).

Верификация и Валидация

Часто эти термины используются как синонимы, но в тестировании ПО их значение принципиально различно. Четкое разграничение верификации и валидации — это ещё одна "слепая зона", которую мы устраняем.

• Верификация ("Правильно ли мы создаем продукт?"):
  • Сущность: Набор действий для проверки того, что программное обеспечение правильно реализует конкретную функцию согласно спецификации. Это проверка внутренней согласованности продукта с его проектной документацией и стандартами.
  • Методы: Включает проверку документации (требований, архитектуры), ревью кода, инспекции, статический анализ кода (без запуска программы).
  • Применение для НИИ: На этапе проектирования верификация может включать проверку ER-диаграмм на соответствие требованиям к данным, а также ревью кода, который реализует алгоритмы расчета бюджета проекта, чтобы убедиться, что он написан согласно лучшим практикам и архитектурным решениям.
• Валидация ("Создаем ли мы правильный продукт?"):
  • Сущность: Набор действий для проверки того, что созданное программное обеспечение соответствует требованиям заказчика и ожиданиям конечных пользователей. Это проверка внешней согласованности продукта с реальными потребностями бизнеса.
  • Методы: Требует исполнения кода (динамическое тестирование) и включает модульное, интеграционное, системное и пользовательское приемочное тестирование.
  • Применение для НИИ: Руководители проектов и научные сотрудники НИИ используют готовую систему для управления своими проектами. Валидация будет заключаться в том, чтобы убедиться, что система действительно помогает им эффективно планировать, отслеживать прогресс, формировать отчеты и вести учет публикаций, а не просто выполняет отдельные функции.

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

Методы и Инструменты Тестирования

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

Методы тестирования:

• Тестирование "черного ящика" (Black-Box Testing): Тестировщик не имеет доступа к внутреннему устройству системы (коду, архитектуре), а проверяет функциональность, взаимодействуя с интерфейсом пользователя и основываясь на спецификации требований.
• Тестирование "белого ящика" (White-Box Testing): Тестировщик имеет доступ к внутреннему коду и структуре системы, что позволяет проверять внутреннюю логику, покрытие кода, пути выполнения. Часто используется в модульном и интеграционном тестировании.

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

• Для модульного тестирования: Встроенные фреймворки в языках программирования (например, JUnit для Java, Pytest для Python).
• Для функционального и интеграционного тестирования: Selenium (для веб-приложений), Cypress, Playwright. Эти инструменты позволяют эмулировать действия пользователя в браузере и проверять отклик системы.
• Для нагрузочного тестирования: Apache JMeter, LoadRunner.
• Для управления тестовыми случаями и дефектами: Jira, TestLink, Zephyr.

Примеры тестовых сценариев для ИС "Проектного НИИ":

Вид тестирования	Описание сценария	Ожидаемый результат
Функциональное	Сценарий 1: Пользователь с ролью "Руководитель проекта" создает новый проект, указывает название, даты начала/окончания, бюджет, прикрепляет сотрудников и грант.	Проект успешно создается, отображается в списке проектов, привязанные сотрудники и грант корректно отображаются в карточке проекта. Данные о бюджете гранта уменьшаются на сумму, выделенную на проект.
Интеграционное	Сценарий 2: После создания публикации в модуле "Публикации", она автоматически связывается с соответствующим проектом и профилем автора.	Публикация появляется в списке публикаций, связанных с проектом, и в разделе "Публикации" в профиле автора.
Нагрузочное	Сценарий 3: 100 пользователей одновременно пытаются получить доступ к странице "Список проектов" и обновить данные о статусе 10 различных проектов.	Система обрабатывает запросы без задержек, время отклика страницы не превышает 2 секунды. Все изменения статусов проектов сохраняются корректно без ошибок конкурентного доступа.
Тестирование безопасности	Сценарий 4: Попытка несанкционированного доступа к финансовым данным грантов через SQL-инъекцию или подбор пароля.	Система должна предотвратить несанкционированный доступ, корректно обработать попытку инъекции без раскрытия данных или предоставить сообщение об ошибке аутентификации без компрометации системы.
Приемочное	Сценарий 5: Заказчик (директор НИИ) генерирует отчет по всем активным грантам за последний квартал.	Отчет формируется корректно, содержит все необходимые данные (название гранта, руководитель, освоенный бюджет, остаток), соответствует утвержденному формату и позволяет принять управленческие решения.

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

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

Заключение

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

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

Особое внимание уделено проектированию базы данных, где, помимо классической реляционной модели и ER-моделирования, были детально исследованы современные нереляционные (NoSQL) и NewSQL решения, предлагающие гибкость и масштабируемость для обработки разнородных научных данных. Процесс нормализации БД, обеспечивающий целостность и минимизацию избыточности, был разобран до мельчайших деталей.

Ключевым аспектом работы стало рассмотрение архитектурных решений, где трехзвенная архитектура предложена как оптимальный выбор для обеспечения устойчивости, масштабируемости и безопасности системы "Проектного НИИ". Был предложен конкретный технологический стек, включающий СУБД (PostgreSQL/Oracle, с возможностью дополнения MongoDB/Neo4j), языки программирования для backend (Python/Java) и frontend (JavaScript-фреймворки), а также инструменты контейнеризации (Docker, Kubernetes), что позволило восполнить "слепые зоны" многих аналогичных работ. Детальное описание принципов проектирования пользовательского интерфейса и ключевых алгоритмов обработки данных стало важным практическим дополнением.

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

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

В качестве направлений для дальнейшего развития системы можно предложить:

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

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

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

1. Бекаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2003. СПб: изд. BHV, 2004. 752 с.
2. Горев А. и др. Эффективная работа с СУБД. СПб: изд. Питер, 1997. 704 c.
3. Карпов Б. Microsoft Access 2000: справочник. СПб: Издательство «Питер», 2000. 416 с.
4. Карпова Т. С. Базы данных: модели, разработка, реализация. СПб: Питер, 2001. 304 с.
5. Конолли Т. Базы данных: проектирование, реализация и сопровождение. Теория и практика. 2-е изд. Пер. с англ. М.: Издательский дом Вильямс, 2001. 1120 с.
6. Михеева В., Харитонова И. Microsoft Access 2002. СПб: БХВ-Петербург, 2003. 1040 c.
7. Стоцкий Ю. Самоучитель Office 2000. СПб: Издательство «Питер», 1999. 576 с.
8. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А. Д. Хомоненко. СПб: КОРОНА принт, 2004. 736 с.
9. Шафрин Ю.А. Информационные технологии: В 2 ч. Ч.2: Офисная технология и информационные системы. М.: Лаборатория Базовых Знаний, 1999. 336 с.
10. Жизненный цикл ПО – методологии и этапы разработки программного обеспечения. URL: https://skillbox.ru/media/code/zhiznennyy-tsikl-po-metodologii-i-etapy-razrabotki-programmnogo-obespecheniya/ (дата обращения: 16.10.2025).
11. Что такое ER-диаграмма и как ее создать? URL: https://www.lucidchart.com/pages/ru/chto-takoe-er-diagramma-i-kak-ee-sozdat (дата обращения: 16.10.2025).
12. Что такое диаграмма взаимосвязи объектов? URL: https://miro.com/ru/guides/er-diagrams/ (дата обращения: 16.10.2025).
13. Семантическое моделирование. Проектирование БД с помощью ER-модели. URL: https://habr.com/ru/companies/timeweb/articles/739190/ (дата обращения: 16.10.2025).
14. Что такое реляционная база данных? URL: https://aws.amazon.com/ru/relational-database/ (дата обращения: 16.10.2025).
15. Реляционные базы данных: основные принципы, структура и характеристики. URL: https://cloud.yandex.ru/docs/managed-postgresql/concepts/relational-database (дата обращения: 16.10.2025).
16. Реляционная модель данных. URL: https://ru.hexlet.io/courses/db-basics/lessons/relational-model/theory_unit (дата обращения: 16.10.2025).
17. Нормализация базы данных: для чего нужна нормализованная бд. URL: https://gitverse.ru/blog/normalization-database/ (дата обращения: 16.10.2025).
18. Что такое нормализация баз данных? URL: https://otus.ru/journal/chto-takoe-normalizatsiya-baz-dannyh/ (дата обращения: 16.10.2025).
19. Примеры и принципы нормализации реляционных баз данных (БД). URL: https://decosystems.ru/blog/normirovaniye-baz-dannykh-dlya-chego-nuzhna-normalizovannaya-bd/ (дата обращения: 16.10.2025).
20. Нормализация данных: что это и зачем их нормировать — правила нормирования данных в БД. URL: https://practicum.yandex.ru/blog/normalizatsiya-dannyh/ (дата обращения: 16.10.2025).
21. Описание нормализации базы данных. URL: https://support.microsoft.com/ru-ru/office/%D0%BE%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8-%D0%B1%D0%B0%D0%B7%D0%B0-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-b4618037-d254-47cd-9f4c-83677336b1d5 (дата обращения: 16.10.2025).
22. Что такое нормализация баз данных? URL: https://www.1cbit.ru/company/news/chto-takoe-normalizatsiya-baz-dannykh/ (дата обращения: 16.10.2025).
23. Что такое база данных. URL: https://azure.microsoft.com/ru-ru/resources/cloud-computing-dictionary/what-is-a-database (дата обращения: 16.10.2025).
24. Что такое базы данных, и зачем им СУБД и SQL. URL: https://skillfactory.ru/blog/chto-takoe-bazy-dannyh (дата обращения: 16.10.2025).
25. База данных: что такое БД, их типы, свойства, структура — примеры использования и управления таблицами баз данных. URL: https://practicum.yandex.ru/blog/chto-takoe-baza-dannyh/ (дата обращения: 16.10.2025).
26. База данных: что это, виды, типы + примеры. URL: https://kokoc.com/blog/chto-takoe-baza-dannyh/ (дата обращения: 16.10.2025).
27. Информационная система: что такое, основные принципы и преимущества. URL: https://skyeng.ru/articles/chto-takoe-informacionnaya-sistema-opredelenie-principyi-i-preimuschestva/ (дата обращения: 16.10.2025).
28. Что понимается под информационной системой? URL: https://www.bpium.ru/blog/chto-takoe-informacionnaya-sistema-funkcii-klassifikacii-i-etapy-vnedreniya (дата обращения: 16.10.2025).
29. Информационные системы: определение и методологии создания. URL: https://otus.ru/journal/informatsionnye-sistemy-opredelenie-i-metodologii-sozdaniya/ (дата обращения: 16.10.2025).
30. Различные виды тестирования ПО. URL: https://www.atlassian.com/ru/agile/testing/types-of-testing (дата обращения: 16.10.2025).
31. Теория тестирования ПО просто и понятно. URL: https://habr.com/ru/articles/588826/ (дата обращения: 16.10.2025).
32. Виды и типы тестирования программного обеспечения. URL: https://qa.studio/blog/types-of-testing-po/ (дата обращения: 16.10.2025).
33. Виды Тестирования Программного Обеспечения. URL: https://protesting.ru/basics/vidy-testirovaniya-po.html (дата обращения: 16.10.2025).
34. Виды тестирования программ в разработке | Типы проверок в тестировании. URL: https://gb.ru/blog/vidy-testirovaniya-po/ (дата обращения: 16.10.2025).
35. Чем отличаются верификация и валидация в тестировании? URL: https://qarocks.ru/chem-otlichayutsya-verifikatsiya-i-validatsiya-v-testirovanii/ (дата обращения: 16.10.2025).
36. Разница между верификацией и валидацией. URL: https://habr.com/ru/articles/692068/ (дата обращения: 16.10.2025).
37. Валидация и верификация. URL: https://qa.studio/blog/verifikatsiya-i-validatsiya/ (дата обращения: 16.10.2025).
38. Что такое верификация и валидация в тестировании ПО. URL: https://sky.pro/media/chto-takoe-verifikaciya-i-validaciya-v-testirovanii-po/ (дата обращения: 16.10.2025).