Внутреннее взаимодействие с заказчиком при проектировании. Заказчик и Исполнитель – взаимоотношения как основа успеха проекта

Общими этапами взаимодействия с заказчиком являются следующие моменты:

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

Важной формой взаимодействия с заказчиком является документация, разрабатываемая в ходе реализации проекта в соответствии с требованиями ГОСТ 34 и RUP.

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

В мире уже давно признано, что управление проектами - особая область менеджмента, применение которой дает ощутимые результаты. Профессионалы в этой области высоко ценятся (в США это третья по средней величине оплаты профессия после юристов и врачей), а сама методология управления проектами стала фактическим стандартом управления на многих тысячах предприятий и применяется в той или иной степени практически во всех крупных корпорациях. В прошлом году приняты стандарты управления проектами ANSI, разработан проект стандартов управления проектами ISO 10006.

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

Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)
Проектирование структуры программы
Кодирование (набор программного кода согласно проектной документации)
Тестирование и отладка
Внедрение программы
Сопровождение программы
Утилизация

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

UML - является графическим языком для визуализации, описания параметров, конструирования и документирования различных систем (программ в частности). Диаграммы создаются с помощью специальных CASE средств, например Rational Rose (http://www-01.ibm.com/software/rational/) и Enterprise Architect (http://www.sparxsystems.com.au/). На основе технологии UML строится единая информационная модель. Приведенные выше CASE средства способны генерировать код на различных объектно-ориентированных языках, а так же обладают очень полезной функцией реверсивного инжиниринга. (Реверсивный инжиниринг позволяет создать графическую модель из имеющегося программного кода и комментариев к нему.)

Рассмотрим типы диаграмм для визуализации модели (это must have, хотя типов гораздо больше):

Диаграмма вариантов использования (use case diagram)

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

Диаграмма классов (class diagram)

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

Диаграмма состояний (statechart diagram)

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

Диаграмма последовательности (sequence diagram)

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

Диаграмма кооперации (collaboration diagram)

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

Диаграмма компонентов (component diagram)

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

Диаграмма развертывания (deployment diagram)

Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются.
Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели.

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

Я убежден, что программист в первую очередь это кодер – он НЕ должен общаться с заказчиком, НЕ должен задумываться об архитектуре системы, не должен изобретать интерфейс к программе, он только должен кодировать – реализовывать алгоритмы, функционал, внешний вид, юзабилити, но не более…. Проектировщик же должен начиная от абстрактных диаграмм (описывающих предметную область) до диаграмм представляющих структуру данных, классов и процессов их взаимодействия, детально шаг за шагом все расписать. То есть сложность работы и зарплата проектировщика должна быть на порядок выше чем у программиста == кодера. Простите за крамолу....

1.1. Взаимодействие с Заказчиками (Основные функции)

1.1.1. Поиск заказов

7.2.3.1. По вопросам информации о продукции

1.1.2. Преддоговорная работа с Заказчиком

Регламентирующие документы

2.2.1.2.1. Преддоговорная работа с Заказчиком СТП-1-01

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.2.1.1. Требования потребителя относительно продукции, включая требования к готовности, доставке и поддержанию

7.2.2.4. Определение возможности достижения соответствия определенным требованиям

// Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

1.1.3. Формирование Технического задания

Регламентирующие документы

2.2.1.2.2. Порядок анализа и заключения контракта СТП-2-01 // Стандарты предприятия предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.2.1.2. Требования, не установленные потребителем, но необходимые для предназначаемого или установленного применения // Определение требований потребителя / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.2.1.3. Обязательства, связанные с продукцией, включая обязательные требования и положения законодательства // Определение требований потребителя / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

// Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.2.2.2. Подтверждение требований потребителя до их принятия, если потребитель не предоставляет письменного изложения требований // Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.2.2.3. Выяснение изменений требований контракта или заказа, отличающихся от ранее представленных (например, при торгах или ссылках) // Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.1.1. Определение стадий процессов проектирования и/или разработки

7.3.2.2. Применимые законодательные и обязательные требования

7.3.2.3. Применимые данные, полученные от подобных предыдущих разработок // Входные данные для проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.2.4. Другие требования, важные для проектирования и разработки // Входные данные для проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.4.1. Оценка возможности выполнения требований

1.1.4. Заключение Договоров

Регламентирующие документы

2.2.1.2.3. Положение о договорной работе с Заказчиком (СТП-3-01) // Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

1.1.5. Контроль за выполнением договорных обязательств

Регламентирующие документы

2.2.1.2.3.2. Порядок анализа изменений и внесения изменений в Договорные документы // Положение о договорной работе с Заказчиком (СТП-3-01) / Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

2.2.1.2.4.1. Процедура обработки жалоб и претензий Заказчика

2.2.1.2.4.2. Процедура устранения замечаний Заказчика // Положение о корректирующих и предупреждающих действиях (СТП-4-01) / Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.2.3.2. Обработка запросов, контрактов, заказов, включая изменения // Связь с потребителем / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

1.2. Планирование работ по проектам (Основные функции)

1.2.1. Уточнение состава комплекса и объемов разработки

Регламентирующие документы

// Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.2.2.1. Определение требований к продукции // Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

1.2.2. Планирование обеспечения качества проекта

Регламентирующие документы

2.2.1.2.5. Состав и порядок разработки программы обеспечения качества проекта (СТП-5-01) // Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.1.1. Установление целей по качеству для продукции, проекта или контракта

7.1.3. Определение действий по проверке и утверждению и критерии приемлемости // Планирование процессов реализации / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.2.2.5. Фиксация результатов анализа и последующих прослеживающих действий (см. п.5.5.7) // Анализ требований к продукции / Процессы, связанные с потребителем / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.1.2. Определение действий по анализу, проверке и утверждению для каждой стадии проектирования и/или разработки // Планирование проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

1.2.3. Формирование частных технических заданий на разработку составных частей комплекса

Регламентирующие документы

2.2.1.2.7. Технология реализации проектов. Этапы и порядок проведения работ (СТП-7-01) // Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

1.2.4. Планирование работ по проекту

Регламентирующие документы

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.1.2. Определение потребности в установлении процессов и документации, обеспечении ресурсами и инфраструктурой, специфичными для продукции // Планирование процессов реализации / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

1.2.5. Координация и оперативный контроль выполнения работ

Регламентирующие документы

2.2.1.2.4.3. Процедура корректирующих действий // Положение о корректирующих и предупреждающих действиях (СТП-4-01) / Стандарты предприятия предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

2.2.1.2.6. Положение о планировании работ (СТП-6-01) // Стандарты предприятия Эллат (СТП) / Документы системы менеджмента качества / Внутренние нормативные документы / Регламенты

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.3.4.2. Выявление проблем и выработка предложений о прослеживающих действиях // Анализ проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.7. Управление изменениями проектирования и разработки

1.3. Разработка конструкторской, программной и эксплутационной документации (Основные функции)

1.3.1. Разработка документации на аппаратную часть комплекса

Регламентирующие документы

2.3.3.3. План работ для отдела разработки и производства аппаратного обеспечения

1.3.2. Разработка программной части комплекса

Регламентирующие документы

2.3.3.4. План работ для отдела разработки и производства программного обеспечения // Программы и планы мероприятий / Организационно-распорядительные документы компании / Регламенты

1.3.4. Анализ и утверждения результатов проектирования

Регламентирующие документы

Требования к системе менеджмента качества ИСО9000:2000 Раздел 7

7.3.3.1. Соответствуют входным требованиям проектирования и разработки

7.3.3.2. Предоставляют надлежащую информацию для операций по производству и услугам (см. п.7.5) // Выходные данные проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.3.4. Определяют характеристики продукции, являющиеся существенными для ее безопасного и надлежащего применения // Выходные данные проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.5.1. Соответствие выходных данных входным требованиям // Проверка проектирования и разработки / Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

7.3.6. Утверждение результатов проектирования и разработки // Проектирование и разработка / РЕАЛИЗАЦИЯ ПРОДУКЦИИ

Обучение, Развитие, Тренинги

Ключевые слова:

1 -1

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

Первичными является звонок или e-mail , которые попадают на обработку к менеджеру по работе с клиентами. Менеджер рассказывает об услугах компании "Бихайв", дает ответы на все интересующие вопросы и объясняет дальнейший процесс взаимодействия заказчику.

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

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

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

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

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

*Процесс от звонка до подписания договора обычно занимает не более 1-2 дней.

После подписания договора и обмена электронными сканированными копиями заказчик оплачивает аванс, сумма которого обычно составляет 50% от общей суммы договора.

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

* Стоит понимать, что техническое задание является очень важным документом одновременно и для исполнителя, и для заказчика. Оно позволяет спроектировать и выполнить интернет-проект качественно и в срок.

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

Иногда заказчику трудно описать свои услуги самому или на это просто нет времени. В этом случае исполнитель готов выполнить работы по написанию недостающего контента на сайт (картинки, тексты, видео и т.п).

* Предоставление заказчиком необходимых материалов критически важен, так как:

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

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

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

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

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

Как только недостающие материалы получены. Начинается важный этап разработки сайта в соответствии с утвержденным ТЗ.
Данный этап включает большое количество типов работ: это кроссбраузерная верстка макетов сайта, разработка необходимых шаблонов дизайна для выбранной системы управления контентом (CMS), установка и настройка самой CMS, установка необходимых модулей и компонентов, разработка недостающих модулей, комплексная проработка алгоритмов функционирования веб-сайта, наполнение сайта контентом, разворачивание проекта на техническом домене и переход к тестированию.

Тестирование интернет-проекта проводят специалисты исполнителя, все ошибки и замечания устраняются, сайт тонко настраивается на работу.

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

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

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

После проведения окончательного расчета вместе с документами и сайтом заказчик получает руководство пользователя, копию сайта на DVD и бесплатную техническую поддержку в течение 2-4 недель с момент сдачи-приемки сайта.

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

Схема работ по услугам "Комплексное развитие сайта", а также "Продвижение сайта" структурно повторяет описанный выше процесс взаимодействия заказчика и исполнителя и поэтому подробного описания не требует.

Надеемся, что описанная схема взаимодействия прозрачна и понятна. Если еще остались вопросы, то просим

Проект:	Распределение запросов к электронному каталогу по поисковым индексам и поисковым терминам
Рамки проекта:	13.02.2006 - 05.06.2006
Заказчик:	Научная библиотека Петрозаводского государственного университета.
Ответственные:	Горшкова Галина Анатольевна, заведующая отделом компьютерной обработки документов и создания каталогов. Эл. почта: . Раб. тел.: 719602. Библиотека: каб. 102. Гурьев Дмитрий Борисович, ведущий программист РЦНИТ. Эл. почта: . Раб. тел.: 784775. Интернет-центр.
Инструктор:	Кулаков Кирилл Александрович. Эл.почта: . Раб.тел.: 711015. 215 каб.
Информация для инструктора:	Группа номер 13
Связанные документы:	Обзор проекта План проекта График работы (диаграмма Гантта) Спецификация требований Проектирование Тестирование Документ реализации Документ тестирования Взаимодействие с заказчиком Связь с разработчиками Отчёты Прогресс разработки Глоссарий Руководство пользователя

Первая встреча с заказчиком.

На первой встрече команда разработчиков была представлена заказчику. Заказчик, в свою очередь рассказал про научную библиотеку ПетрГУ.

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

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

Были также представлены первичные требования к реализуемому проекту. Одно из требований – это эффективное составление статистики. То есть статистика должна отображаться спустя разумное время после отправки запроса. В связи с этим требованием, разработчикам было предложено использовать процедуры на стороне сервера на языке PL/SQL .

Вторая встреча с заказчиком.

Заказчик предоставил разработчикам логин и пароль для входа в систему электронного каталога, предоставив для работы копии двух таблиц – лог-таблицу и таблицу поисковых индексов.

Гурьев Дмитрий Борисович более подробно ознакомил нас с работой в клиенте СУБД Oracle SQL*Plus. Команда познакомилась с работой электронного каталога.

Система "Фолиант" работает на основе стандарта RusMark, который содержит порядка 99 полей. Каждая библиотека, работающая с АИБС "Фолиант" выбирает поля и подполя, которые она будет использовать. Существуют специальные ГОСТы, описывающие правила хранения библиотечных данных. Поскольку полей большое количество, то создали систему поисковых индексов. Существуют служебные и общедоступные индексы.

Пользователи каталога делятся на внутренних и внешних. Каждому отделу или сотруднику в соответствие ставятся свои права. Каждая запись об объекте разбирается на отдельные элементы и в целом виде не храниться.

Третья встреча с заказчиком.

Заказчик предоставил нам четкие требования в письменном виде.

Заказчика интересует статистика следующего вида:

Количество запросов к электронному каталогу.

За последний месяц по дням.
Учет по месяцам в течение текущего года.
Учет по годам.
Создать ретроспективу сведений.

Список запросов по каждому поисковому индексу, в которых результат поиска был нулевой.

Список часто встречающихся запросов.

Анализ выполнения запросов за определённый период. В отчёте должны быть отражены следующие статистики:

Количество запросов.
Количество уточняющих запросов.
Количество сложных запросов.
Количество результативных ответов.
Количество ответов с нулевым результатом.
Автор
Автор рец. произв.
Вид документа.
Географическая рубрика.
Дата ввода.
Дата издания.
Заглавие.

Чётвёртая встреча с заказчиком.

Специалист со стороны заказчика Гурьев Д.Б. разъяснил тонкости установки и настройки утилиты SQL*Plus. Решение проблемы запуска программы заключалось в установке пакета SQL*Net, также Гурьев Д.Б. предоставил точные названия таблиц для разработчиков, а также добавил в распоряжение команды ещё одну таблицу. Специалист изучил документ архитектуры и предложил практически реализовать все виды архитектуры и выбрать более оптимальную. При этом желательно не перестраивать лог - таблицу и максимально, решая конкретную задачу, обобщить данные из лог - таблицы для дальнейшего использования в различных локальных статистиках.

Заказчик Горшкова Г.А. ознакомилась с документом требований, утвердив их.

Пятая встреча с заказчиком.

Специалист со стороны заказчика Гурьев Дмитрий Борисович был приглашён для установки на учебный сервер ПетрГУ программного обеспечения необходимого для работы с СУБД "Oracle". К этому процессу был привлечён также со стороны университета Пономарёв Вадим Анатольевич, который имеет администраторский доступ к серверу ПетрГУ.