37
сообщениях. Впрочем, в интересах владельца веб-сайта, чтобы
информационные сообщения были интересны для подписчиков.
Функциональная структура веб-сайта должна представлять список
информационных материалов и сервисов, которые должны быть
представлены на нем.
Логическая структура веб-сайта разрабатывается на основании из
предполагаемой модели поведения различных целевых групп на веб-сайте.
При этом желательно учитывать маркетинговые цели предприятия
относительно его целевой группы. Фактически поведение посетителя веб-
сайта представляет собой коммуникационное действие, при котором
адресант – создатель веб-сайта передает сообщение – информацию,
размещенную на веб-сайте, и получает ответное сообщение адресата,
выраженное его поведением на веб-сайте и достижениями конверсий. В
самом идеальном случае посетитель ведет себя в полном соответствии с
предполагаемой моделью поведения.
38
II Проектная часть
2.1 Разработка проекта автоматизации
При разработке документации для государственных и серьезных
частных заказчиков у исполнителей обычно нет выбора — в требования по
документированию ТЗ вписано соблюдение стандартов. На практике
приходилось сталкиваться с различными примерами недопонимания
структуры стандартов, того, что должно быть в документах и зачем эти
документы нужны. Для разработки настоящего проекта была выбрана
модель жизненного цикла ГОСТ 34*.
В серии 34, о которой идет речь, существует всего 3 основных
стандарта по документированию:
1. ГОСТ 34.602-89 Техническое задание на создание
автоматизированной системы
Самый популярный стандарт по разработке технического задания
(ТЗ). Единственное, не стоит забывать, что он тесно связан с другими
стандартами серии и, если было написано ТЗ, выполненное по данному
стандарту, крайне желательно придерживаться и других стандартов, даже
если об этом нет прямых требований.
2. ГОСТ 34.201-89 Виды, комплектность и обозначения документов
при создании автоматизированных систем.
Это базовый документ, в котором приводится полный перечень
документации ГОСТ 34, рекомендации по кодированию документов, к
каким стадиям проекта относятся документы (стадии описываются в ГОСТ
34.601-90), а также как их можно объединить между собой.
Фактически, этот стандарт представляет собой большую таблицу с
комментариями.
3. РД 50-34.698-90 Автоматизированные системы. Требования к
содержанию документов.
39
Объемный стандарт, с различной степенью детальности
описывающий содержание проектных документов. В качестве индекса
используется упомянутый выше ГОСТ 34.201-89.
К стандарту РД 50-34.698-90 существует множество вопросов и
трактовок его положений, которые ввиду их неконкретности, часто
понимают по-разному заказчик и исполнитель или даже члены проектной
команды.
Рассмотрим теперь плюсы и минусы стандартов.
Минусы стандартов
Основной минус стандартов — они устарели. В них заложено
устаревшее представление об архитектуре автоматизированной системы,
например:
приложения двухуровневые, состоящие из клиентской программы
и сервера СУБД;
структура таблиц базы данных, которая описана, даст
представление о логической модели данных;
пользовательский интерфейс однооконный;
отчетов в системе немного, все они бумажные и печатаются на
принтере;
разрабатываемая программа ориентирована на решение «задачи
обработки информации», которая имеет четкий вход и выход, а
также узко специализирована. В основе обработки информации
лежит «алгоритм». Иногда «алгоритмов» бывает несколько;
администратор базы данных понимает, какая информация лежит в
таблицах и активно участвует в редактировании системных
справочников.
40
Плюсы стандартов
Любой стандарт неплох тем, что он позволяет заказчику и
исполнителю говорить на одном языке и дает гарантию, что, по крайней
мере, претензий «по форме» к передаваемым результатам у заказчика не
будет.
А стандарты ГОСТ 34 неплохи еще и тем, что они составлялись
профессионалами, обкатывались годами и у них есть четкая цель —
максимально полно описать на бумаге сложную абстрактную сущность,
которую представляет собой любая автоматизированная система
управления.
Когда требуется грамотно поставить задачу зарубежным
подрядчикам, которые не ознакомлены с ГОСТами, можно также
опираться на эти стандарты, а точнее на их содержимое, смысловую
составляющую.
Стандарт делит все документы на две части — время и предметная
область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно
это деление (колонки «Стадия создания» и «Часть проекта»).
Стадии создания АСУ
Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к
документированию из них три:
Эскизный проект (ЭП).
Технический проект (ТП).
Разработка рабочей документации (РД).
Эскизный проект разрабатывается только после стадии «Техническое
задание» и служит для разработки предварительных проектных решений.
Технический проект описывает будущую информационную систему.
Документы стадии ТП должны после прочтения оставлять после себя
41
полную ясность в предлагаемых подходах, методах, архитектурных и
технических решениях. На следующей фазе уже поздно будет описывать
подходы и обосновывать технические решения, так что фаза ТП является
ключом к успешной сдаче работ, так как все многообразие требований ТЗ
должно находить отражение в документах фазы ТП. На этапе ТП система
может вообще не существовать.
Рабочая документация предназначена для успешного развертывания,
ввода в действие и дальнейшей эксплуатации новой системы. Это
документы, содержащие совсем конкретные сведения, описывающие
физически существующие сущности, в отличие от фазы ТП, где
описывается будущий проект.
Основные этапы жизненного цикла:
Анализ объекта проектировавание, составление технического задания.
Началом разработки любого проекта составляет постановка задачи, ее
анализ и составление технического задания. Предприятие поставило
конкретную задачу – провести автоматизацию, которая поможет решить
ряд проблем и откроет новые возможности для предприятия. И после
постановки задачи первым делом изучаем бизнес-процессы работы
предприятия.
Интересующая часть бизнес-процесса предприятия заключалась в
следующем:
принятие заказов менеджерами
отправка заказов на изготовление поварам
прием готовой продукции логистам
доставка продукции до конечного потребителя.
На основе полученной информации принимается решение о
разработке технического задания. В техническом задании мы детально
42
указываем весь необходимый функционал и все это согласовывается с
заказчиком. Из основного функционала можно выделить несколько
функций, которые раскрывают всю суть проекта.
Входные данные:
Каталог продукции с основными заданными характеристиками;
Поступление изменения статусов заказов из CRM Smartomato;
Поступление заказов из CRM Smartomato;
Необходимая информация для создания промокодов;
Задание статуса для вывода на печать соответствующей
этикетки;
Баннеры;
Информация для статичных страниц;
Добавление категорий;
Добавление сайтов с указанными свойствами;
Привязка каталога за необходимой категорией;
Привязка категории за необходимым сайтом;
Выбор параметров для сортировки продукции;
Выбор категории для отображения соответствующей
продукции;
Ввод контактной информации для оформления заказов,
номеров кредитных карт;
Настройки ресурса:
o Максимальная сумма использования баллов;
o Минимальная сумма для заказа;
o Блюдо-подарок до установленной суммы заказа;
o Зона доставки в виде полигона;
43
Выходные данные:
Каталог продукции в соответствии с выбранной категорией и
сайтом;
Статистика заказов в личном кабинете;
Статус заказа (принят, в производстве, приготовлен, у курьера,
доставлен, отменен);
Статус заказа в виде смс-сообщения (для статуса принят и
отменен);
Отправка в Google Cloud Print информации на печать;
Этикетка продукции;
Баннеры;
Отправка заказа в CRM Smartomato;
Отправка служебной информации информации в систему
интернет-эквайринга Сбербанк.
Разработанное техническое задание позволяет приступить к
непосредственной разработке проекта, в котором установлен весь
необходимый функционал.
Данный этап является очень важным, так как неверно составленное
техническое задание может повлиять на репутацию компании,
обусловленная не верным толкованием исходной задачи. Непонимание со
стороны технического писателя и заказчика может привести к срыву
установленных сроков и финансовых потерь как со стороны исполнителя,
так и заказчика. По моему мнению это самые важные риски, на которые
следует обращать внимание при разработке информационных проектов.
Эскизный проект
Эскизный проект для данного проекта представляет собой
разработанный дизайн-проект, который утверждается заказчиком. В
эскизном проекте отрисованы все необходимые элементы для
44
разработчика конечного пользователя системы. На рисунках 4 – 10
представлен эскизный проект интернет-магазина.
Рис. 4. Главная страница
45
Рис. 5. Каталог продукции
46
Рис. 6. Продукция