Разработка АРМ сотрудника рекламного агентства

8. Требования к документированию.

8.1. Перечень подлежащих  разработке документов.

• нормативно-техническая документация;
• отчет о выполненной работе;
• отчет и утверждение концепции;
• техническое задание;
• эскизная документация на ИС и ее части;
• документация на ИС и ее части;
• документация на поставку комплектующих изделий;
• рабочая документация на ИС и ее части;
• ежемесячные отчёты заказчику;
• справочный документ Readme.

8.2. Перечень документов  на машинных носителях

• ежемесячные отчёты заказчику;
• справочный документ Readme.

9. Источники разработки. Используемыми  документами для создания АРМ сотрудника клиентского отдела рекламного агентства «Парус», сформированными в ходе анализа объекта автоматизации, являются: схема организационной структуры; перечень заданий на разработку специализированных (новых) технических средств; схема автоматизации; описание массива информации; описание комплекса технических средств.

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

2.2 Календарный план

Календарный план – это  совокупность сроков начала и окончания  работ, совершения событий проекта, один из главных инструментов управления проектом. Он представлен в таблице 1 «Календарный план».

Таблица 1.Календарный план

№ Этапа	Наименование основных этапов	Срок выполнения начало-окончание  (число, м-ц, год)	Расчетная цена этапа, руб.  в % к договорной цене
1	2	3	4
1	Анализ и формирование требований к разработке АРМа	30.11.11– 8.12.2011	10000 ------------- 15%
2	Анализ существующего ПО предприятия, выработка плана интеграции управляющей  системы сайта	9.12.11 – 14.12.11	5000 ------------- 7,5%
3	Проектирование АРМа(концепция, модель)	15.12.11 – 30.12.11	10000 ------------- 12%

  Продолжение таблицы 1. Календарный план

№ Этапа	Наименование основных этапов	Срок выполнения начало-окончание  (число, м-ц, год)	Расчетная цена этапа, руб.  в % к договорной цене
4	Создание скрипта для запросов в БД	4.01.12 – 10.01.12	7000 ------------- 10%
5	Создание формы регистрации пользователя/скрипта  проверки правильности введенных данных	11.01.12 – 14.01.12	5000 ------------- 7,5%
6	Разработка скрипта автоматически  создающего лист заявки на оказание услуг	15.01.12 – 18.01.12	4000 ------------- 6%
7	Разработка скрипта автоматически  создающего договор между агентством и клиентом	19.01.12 – 22.01.12	6000 ------------- 9%

Продолжение таблицы 1. Календарный  план

№ Этапа	Наименование основных этапов	Срок выполнения начало-окончание  (число, м-ц, год)	Расчетная цена этапа, руб.  в % к договорной цене
8	Разработка скрипта ведущего отчетность о выполненных заявках в агентстве	23.01.12 – 25.01.12	9000 ------------- 13,5%
9	Подготовка к введению системы  в эксплуатацию(настройка всех модулей, скриптов  и опций)	26.01.12 – 6.02.12	5000 ------------- 7,5%
10	Отладка и тестирование	7.02.12 – 14.02.12	3000 ------------- 4,5%
11	Установка программного модуля на рабочее  место работника-А; настройка оборудования и конфигураций	15.02.12 – 23.02.12	2000 ------------- 3%

 

Продолжение таблицы 1. Календарный план

№ Этапа	Наименование основных этапов	Срок выполнения начало-окончание  (число, м-ц, год)	Расчетная цена этапа, руб.  в % к договорной цене
12	Сдача АРМа в эксплуатирование, подготовка отчета о проделанной работе	24.02.12 – 1.03.12	3000 ------------- 4,5%
Итого			66000

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

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

 

3. Анализ и проектирование АРМ сотрудника рекламного агентства «Парус» структурным подходом

3.1 Разработка функциональной модели АРМ

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

Методология SADT (Structured Analysis and Design Technique - методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для  построения функциональной модели системы.

Данная методология при  описании функционального аспекта  информационной системы конкурирует  с методами, ориентированными на потоки данных (DFD). В отличие от них IDEF0 позволяет:

• описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);

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

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

Основу методологии IDEF0 составляет графический язык описания процессов. Модель в нотации IDEF0 представляет собой  совокупность иерархически упорядоченных  и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном  листе.

Модель (AS-IS, ТО-ВЕ или SHOULD-BE) может  содержать 4 типа диаграмм:

• контекстную диаграмму;

• диаграммы декомпозиции;

• диаграммы дерева узлов;

• диаграммы только для экспозиции (for exposition only, FEO).

Рассмотрим IDEF0 модель для модуля заказов в клиентском отделе рекламного агентства «Парус» на рис.1.

 

Рисунок 3.-Контекстная диаграмма, построенная методологией IDEF0

Входящие потоки данных

Данные вводимые пользователем:

• Ф.И.О клиента,
• адрес проживания,
• заявка клиента,
• e-mail,
• создается ID номер заказа.

Управляющие документы

Закон о защите прав потребителей - регламентирует отношения между  клиентом и агентством, а также  следит за выполнением правил предоставления услуг. Заказ формируется в пределах этих норм.

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

Механизмы управления

Клиент непосредственно  указывает вид оказываемой услуги.

Работник-А работает с модулем заказов и может изменять и настраивать его конфигурацию.

Выходящие потоки данных

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

Оформление заявки – это  авто-генерируемый отчёт для клиента, в нём выводится информация о  том, что заказ был оформлен или  нет, приведены контакты и телефоны служб с которыми клиент может  связаться. После того, как работник-А отправил данные о заказе в БД, информация обрабатывается и формируется в бланк заявки, и выводит его на печать.

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

Далее приведена декомпозиция контекстной диаграммы на рис.4.

Рисунок 4. -Декомпозиция контекстной диаграммы

Рассмотрим также модель модуля заказов клиентского отдела агентства «Парус», построенную методологией DFD.

 

Рисунок 5. Контекстная диаграмма построенная методологией DFD.

Следующим шагом является исследование информационной модели ИС.

3.2 Исследование информационной модели АРМ

Разработанная функциональная модель системы отвечает на вопросы  «Что должна делать система?» и «За  счет каких действий может быть достигнут  требуемый результат?». Эта модель также позволяет концептуально  определить наборы данных, используемых в системе. В то же время она  не отвечает на вопрос: «Каким образом  организованы данные в системе?». Для  ответа на него необходимо построить  информационную модель (запроектировать  БД).

Традиционно процедуру проектирования базы данных разбивают на три этапа, каждый из которых завершается созданием  соответствующей информационной модели [1, 20, 21].

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

Этап 2-й. Логическое проектирование - развитие концептуального представления БД с учетом принимаемой модели (иерархической, сетевой, реляционной и т.д.).

Этап 3-й. Физическое проектирование - развитие логической модели БД с учетом выбранной целевой СУБД.

Концептуальное и логическое проектирование вместе называют также  инфологическим или семантическим проектированием.

В настоящее время для  проектирования БД активно используются CASE-средства. в основном ориентированные на использование ERD (Entity - Relationship Diagrams, диаграммы «сущность-связь»). С их помощью определяются важные для предметной области объекты (сущности), отношения друг с другом (связи) и их свойства (атрибуты). Следует отметить, что средства проектирования ERD в основном ориентированы на реляционные базы данных (РБД). и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы проектирования.

ERD были впервые предложены П. Ченом в 1976 г. Основные элементы ERD перечислены ниже [1. 18-21].

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

Экземпляр сущности (запись, строка, в РБД - кортеж) - уникально идентифицируемый объект.

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

Атрибут (столбец, поле) - свойство сущности или связи.

Таблица 1.Атрибуты сущности «Клиент»

Атрибут	Описание
ID клиента	Уникальный номер для идентификации клиента
Ф.И.О.	Фамилия, имя и отчество клиента
Адрес	Адрес проживания
E-mail	Адреса электронной почты
ID заказа	Уникальный номер сделанного данным клиентом заказа

Так как клиент формирует  заказ из предложенного перечня, определим сущность «Услуги» или  «Прайс-лист»

Таблица 2.-Атрибуты сущности «Запись в БД о сформированном заказе»

Атрибут	Описание
ID услуги	Уникальный номер для идентификации товара
Наименование	Полное название услуги
Цена	Стоимость данной услуги
Описание	Подробное описание и характеристики

 

Таблица 3.-Атрибуты сущности «Заказ»

Атрибут	Описание
ID заказа	Уникальный номер для идентификации заказа
Сумма заказа	Подсчитанная стоимость заказа
Оплачен	Да или Нет
ID услуги	Уникальные номера услуги, составляющей данный заказ
Состояние заказа	Поставлен в очередь/разрабатывается/выполнен
Номер счёта	Для оплаты данного заказа
Вид оплаты	Касса/ Переводом на счёт

Составляется ERD-диаграмма, определяя типы атрибутов и проставляя связи между сущностями (рис.6). Связь «Клиент» - «Заказ» - «один-к-одному», а «Заказ» - «Запись в БД о сформированном заказе» - «один-ко-многим». Диаграмма представлена на рисунке 6.

Рисунок 6. ERD-диаграмма модуля заказов.

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

3.3 Изучение поведенческой модели АРМ

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