Уважаемый Анатолий

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

1. Заказчик предоставляет исходные данные для магазина. Он должен также иметь возможность в любой момент своими силами внести в них любые дополнения, уточнения, не привлекая для этого ни программиста, ни администратора сервера. Необходимо будет выбрать такой набор форматов, какие средства обработки исходных данных и какую методику, чтобы иметь необходимую для этого гибкость.
2. На основании предоставленных хозяином магазина данных формируется страница с перечнем изданий и ценой на каждое из них, возможным сроком подписки и перечислением способов доставки. (Заказчик должен иметь возможность своими силами анонсировать новые способы или отказаться от любого из первоначально заявленных). Магазин должен предоставлять возможность размещения дополнительной информации по каждому отдельному изданию в призвольном формате, например, краткое стандарное описание.
3. Изучив представленную в пукте 2 информацию, Покупатель выбирает перечень изданий, срок подписки для каждого из них, способ доставки (для каждого отдельный, либо для всего заказа единый). Отобрав издания, Покупатель может посмотреть, во сколько ему обойдется покупка. Программа производит расчет соответствующей суммы с учетом системы скидок. (Саму таблицу скидок мы ему показываем?) Если сумма Покупателя не устраивает, он может по ходу поменять условия подписки, доставки, количество и ассортимент заказа. (Именно поправить, а не составлять по-новой.)
4. Сделав окончательный выбор, Покупатель переходит к заполнению формы с индивидуальной информацией. Часть предоставляемых сведений обязательна, часть – нет. Первоначальный набор сведений нам дает Заказчик, однако программа должна быть составлена таким образом, чтобы у него всегда оставалась возможность самостоятельно откорректировать набор таких сведений, а также перевести любую конкретную характеристику Покупателя из разряда обязательных в необязательные и наоборот.
5. По завершении заказа, на последней html-странице Покупатель должен увидеть предложение связаться с хозяином электронного магазина и подтвердить заказ (способы должны быть перечислены тут же). Для простоты эту страницу можно сделать статической. Программа заносит все полученные сведения в определенный текстовый файл (указано вами). Возможно также потребуется, чтобы она автоматически по электронной почте уведомляла хозяина магазина о самом факте появления очередного заказа (в частности, это будет полезно, чтобы Заказчик складывал эти “чеки” на своем персональном компьютере в отдельный каталог и хранил на случай какой-либо аварии на сервере).
6. Покупатель тем или иным образом связывается с хозяином магазина. При этом Заказчик должен иметь возможность с помощью браузера связаться с Web-сервером и оперативно получить все сведения, предоставленные данным Покупателем и конкретном его заказе. На деле это означает, что хозяин магазина должен иметь возможность быстро “вычислить” Покупателя по начальным буквам его фамилии, дате заказа или одному из заказанных им изданий. Фактически мы должны построить своеобразную динамически пополняемую систему поиска в массиве сделанных заказов.
7. Обрабатывая тот или иной заказ, Хозяин магазина должен иметь возможность тут же через свой интерфейс сделать на сервере в специальном поле дополнительные записи, комментарии относительно данного Покупателя.
8. Поскольку сведения фактически хранятся в текстовом виде, то есть, в отличие от стандартных баз данных, доступ к ним не оптимизирован, то хозяин магазина должен вероятно иметь возможность просмотреть перечень сделанных заказов, перевести часть их из активного состояния в архив (отдельный файл), который, например, содержит сведения о заказах недельной, месячной давности. В конце отчетного периода (например, раз в неделю или месяц) Заказчик должен иметь возможность получить результаты общей обработки всего набора сделанных за отчетный период заказов (общее количество, общая сумма, раскладка по изданиям и т.д. – уточнить у Заказчика).
9. Весь инструментарий Заказчика, все коммерческие сведения должны быть защищены от просмотра или коррекции со стороны посторонних лиц.

Общеорганизационные вопросы.

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

• исходные данные для электронного магазина Заказчик готовил и хранил в Excel на своем персональном компьютере
• после создания или корректировки этих данных Заказчик экспортировал их в тектовые файлы с табуляторами и пересылал на сервер (по электронной почте, или по ftp - уточнить)
• оперативная работа с заказами ведется на сервере с использованием стандартного браузера по паролевому входу (у Заказчика доступ в Интернет, точнее к вашему серверу постоянный и быстрый?)
• отчетная информация в виде опять текстовых файлов передается обратно на персональный компьютер Заказчика и импортируется в таблицы Excel. Обработка для отчетов производится средствами Excel (или Access)

В качестве языка разработки CGI-программ я бы предпочел выбрать именно Perl, поскольку этот язык специально предназначен для обработки текстов и программы на нем будут гораздо короче, чем на Си. (Следовательно, меньше вероятность того, что в них может появиться ошибка. Иными словами, на этом языке быстрее писать и проще отлаживать CGI-программы.)

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

Предлагаемый план работ:

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

   Согласование внешнего вида web-страниц (дизайн первой страницы сайта – в данную задачу по-видимому не входит), состав заполняемых Покупателем форм, вид интерфейса со стороны хозяина магазина.

   Согласование способа передачи данных от Заказчика на сервер и обратно.

   (разработка предложений и утверждение – 2 дня, максимум 3 дня, если Заказчик будет требовать серьезной переделки)

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

3. Механизм заказа изданий
   (проектирование, кодирование, отладка - 1 день)

4. Механизм сбора сведений о Покупателе
   (проектирование, кодирование, отладка – 1 день)

5. Механизм оперативного поиска в массиве заказов сведений о конкретном Покупателе или заказе. Дополнительные комментарии к данному заказу со стороны хозяина магазина.
   (проектирование, кодирование, отладка – 3-4 дня)

6. Набор стандартных форм для таблиц Excel, которые размещаются на персональном компьютере Заказчика и используются при работе с электронным магазином
   (составление и согласование – 1 день)

7. Размещение программного комплекса на главном сервере, окончательная отладка. Демонстрация перед Заказчиком. Корректировка в соответствии с его индивидуальными пожеланиями.
   (1-2 дня. Либо больше, в зависимости от серьезности затребованных Заказчиком переделок)

8. Написание руководства пользователя (10 страниц), технического оисания (10-20 страниц)
   (3-4 дня)