Разработка веб-порталов

Разработка веб-портала

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

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

Какие задачи решает портал

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

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

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

Роли и пользовательские сценарии

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

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

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

Аналитика, прототип и техническое задание

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

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

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

Архитектура и модель данных

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

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

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

Интеграции и API

Портал может обмениваться данными с 1С, система управления клиентами (CRM), ERP, телефонией, платёжным провайдером, электронной почтой и сервисом документов. Для каждого соединения определяются поля, идентификаторы, направление, частота, лимиты и владелец.

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

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

Интерфейс и дизайн-система

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

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

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

Безопасность и персональные данные

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

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

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

Производительность и надёжность

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

Метрики приложения, базы, очереди и инфраструктуры собираются централизованно. Уведомление связывается с симптомом и инструкцией реакции. Резервные копии проверяются восстановлением, а выпуск имеет план отката.

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

Разработка и тестирование

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

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

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

Запуск, обучение и поддержка

Миграция данных начинается с сопоставления полей, очистки и пробного переноса. Контроль сравнивает количество записей и ключевые значения. Во время переключения ограничиваются изменения в старой системе или применяется согласованная синхронизация.

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

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

Стоимость и состав результата

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

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

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