http://dev.jast.ru 

1. Анализ задачи
JEDOMS

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

1. Первоначальная постановка задачи

1.1. Основные требования к программе со стороны клиента

  1. Периодически обновляемый прайс-лист
  2. Возможность сформировать первичную заявку по этому прайс-листу
  3. Список отправленных первичных заявок
  4. Ответ фирмы на заявку (подтверждение, изменения, отказ)
  5. Возможность внести изменения в заявку на основании ответа и отправить их фирме
  6. Доступ к архиву и текущим состояниям отправленных заявок
  7. Возможность сформировать отложенную заявку (по позициям, отсутствующим в прайсе временно или вообще из-за отсутствия спроса или новизны позиции)

1.2. Основные требования к программе со стороны отдела реализации

  1. Заявка должна содержать данные отправителя (физ. лицо, представитель, организация) и реквизиты прайс-листа, по которому сформирована заявка
  2. До проведения заявки в RS-Balance - возможность внести в заявку изменения и согласовать их с клиентом
  3. Уведомление клиента о фактах получения и проведения заявки
  4. Доступ к аналитической информации, не попадающей в RS-Balance (количество отказов, изменений, заявок по устаревшему прайсу в разрезе клиентов и представителей)
  5. Возможность учета отложенных заявок и последующей работы с ними (в т. ч. извещение отдела поставок)

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

  1. Подготовка и передача на сервер данных прайс-листа (RS-Balance)
  2. Прием и учет данных прайс-листа (Сервер)
  3. Доставка прайс-листа клиентам (Сервер)
  4. Прием прайс-листа (Клиент)
  5. Оформление заявки по прайсу или произвольно (Клиент)
  6. Отправка заявки (Клиент)
  7. Прием и учет заявки от клиента (Сервер)
  8. Доставка заявки в отдел реализации (Сервер)
  9. Доступ к заявке и формирование ответа клиенту (RS-Balance)
  10. Прием и учет ответа отдела реализации (Сервер)
  11. Доставка ответа пользователю (Сервер)
  12. Прием ответа и отправка реакции (Клиент)
  13. Прием и учет ответа клиента (Сервер)
  14. Доставка ответа в отдел реализации (Сервер)

Функции 9-14 могут выполняться несколько раз до завершения работы с заявкой.

1.4. Используемые технологии

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

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

  1. Не все клиенты, имеющие доступ в Интернет (Интранет фирмы) изначально готовы использовать электронную почту, архиваторы и программы закачки файлов
  2. Новые клиенты, потенциальные клиенты и клиенты-физические лица вряд ли вообще будут себе что-либо скачивать в то время, как у конкурентов будет удобный интернет-магазин.
  3. Статистика и прогнозы

1.5 Дополнительные требования к функциональности программы

  1. Клиент должен иметь возможность направить запрос фирме и, в т.ч. разработчику программы в произвольной форме и иметь доступ к ответам фирмы на его запросы и публичным запросам других клиентов.
  2. Клиент должен иметь доступ к информации о важных изменениях прайс-листа, ценовой политики, функциональности программы заявок.
  3. Программа должна быть подготовлена для работы с карточками фирмы.
  4. Программа должна реализовывать индивидуальный подход к клиенту, в т.ч.
    1. состав прайс-листа (розница / весь прайс)
    2. скидки (опт / наличие у клиента карточки / иное)
    3. приоритетность обработки заказов (наша аптека / другой город / новый клиент)
    4. персонификация фирмы (для каждого клиента должен быть ответственный за работу с ним сотрудник отдела реализации)

1.6 Дополнительные требования к реализации программы

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

2. Согласованная постановка задачи

Для обеспечения согласованности требований Первоначальной постановки задачи, в программе должны быть реализованы:

2.1. Электронная почта

  1. Почтовые рассылки (прайс-листов, новостей)
  2. Прием информации (заявок, запросов, ответов) от пользователей (клиентов, сотрудников, RS-Balance)
  3. Доставка ответов клиентам (способных обработать ответную реакцию пользователя)
  4. Хранение истории документов средствами почтовой программы

2.2. RS-Balance

  1. Передача данных прайс-листа на Сервер (по электронной почте)
  2. Прием и проведение заявок
  3. Передача на сервер состояния и изменений по заявкам (по электронной почте)

Доступ к операциям и документам, который не может быть эффективно осуществлен с помощью электронной почты или RS Balance, осуществляется через web-интерфейс Сервера

2.3. WWW-Сервер

  1. Генерация информации для почтовых сообщений и RS Balance
  2. Общий механизм обработки информации, приходящей на сервер через web и email интерфейсы
  3. WWW интерфейс к информации и функциям программы
    1. Для всех
      1. прайс
      2. новости
      3. публичная информация о фирме и товарах
      4. получение информации (опросы, обсуждения)
    2. Для персонала
      1. полученные запросы (от клиентов и персонала)
      2. возможность ответов (клиентам и персоналу)
      3. история документов
      4. подготовка публичной информации
    3. Для клиентов
      1. формирование заявок
      2. персональный прайс
      3. история заявок
      4. информационный обмен с фирмой
      5. загрузка истории в почтовую программу в случае ее потери на компьютере клиента
    4. Для администраторов
      1. управление пользователями сервера
      2. классификация пользователей (управление группами пользователей)
      3. управление правами доступа пользователей (на основе групп)
      4. управление документами (создание шаблонов доступных группам документов и прав)

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

2.4. Типы документов в системе

  1. Прайс-лист
  2. Заявка
  3. Запрос
  4. Новость
  5. Обсуждение
  6. Опрос
  7. Пользователь
  8. Группа пользователей
  9. ...

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

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

2.5. Выводы

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

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

  1. Выбрать адекватную программную платформу и изучить ее возможности (и пределы этих возможностей)
  2. Разработать спецификацию системы, в рамках которой
    1. составить как можно более полный список необходимых документов и операций с ними
    2. выделить общее и частное у объектов системы
    3. построить модель, позволяющую единообразное представление и использование различных типов документов с учетом особенностей каждого типа
    4. описать применение модели к объектам системы
    5. описать основные алгоритмы и структуры данных
  3. Реализовать ядро системы на основе построенной модели
  4. Реализовать минимальный набор функций, достаточный для работы программы заявок с ограниченной функциональностью
  5. Ввести систему в эксплуатацию и дорабатывать ее функциональность

3. План работы и текущее состояние проекта

  1. Анализ задачи
    1. Первоначальная постановка задачи (июль)
    2. Согласованная постановка задачи (авг)
  2. Выбор программной платформы
    1. Формулирование принципиальных вопросов к технологическому решению (июль, авг)
    2. Получение ответов на эти вопросы (разработка пилотных модулей, в т.ч. пилота клиентской части, почтового шлюза, серверных модулей) (июль, авг)
  3. Разработка спецификации
      4. Состояния спецификации
    1. Неупорядоченный набор идей (авг)
    2. Сформулированный набор идей (сент)
    3. Неупорядоченный набор спецификаций (сент)
    4. Упорядоченный набор спецификаций как одна спецификация системы [окт]
    5. Разработка схемы данных [окт]
  4. Реализация системы
    1. Разработка ядра системы
    2. Реализация минимума необходимых для программы заявок функций
    3. Разработка программного кода основных модулей системы
  5. Эксплуатация
    1. Опытная эксплуатация текущей версии
    2. Формулирование требований по исправлению и доработке системы в рамках спецификации
    3. Наращивание функциональности согласно спецификации
    4. Доработка кода существующих эксплуатируемых модулей

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

В настоящий момент завершается подготовка упорядоченного набора спецификаций системы (п. 3.4)

October 05, 2000

 $Name: v1-07 $   (c) 2002-2006, Алексей А. Коврижкин
jean@jast.ru