Смекни!
smekni.com

Автоматизация разработки медиаплана для ООО "Медиа-Групп" (стр. 7 из 13)

- изучение предметной области и разработка структуры хранения данных;

- разработка, согласование и утверждение технического проекта программного продукта;

- реализация проекта на выбранном языке программирования;

- отладка формы;

- тестирование и исправление обнаруженных недостатков.

2.2.6 Порядок контроля и приемки системы

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

Тестирование будет проходить в три этапа:

- проверка правильности заданных расчётов выбранных показателей;

- проверка целостности системы;

- проверка интерфейса системы на соответствие стандарту предприятия.

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

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

По окончании испытательного срока программа допускается к эксплуатации актом внедрения программы в опытную эксплуатацию.

2.2.7 Состав и содержание работ по вводу системы в действие

Подготовка объекта автоматизации сводится к установке необходимого программного обеспечения и обучению персонала.

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

Документирование должно осуществляться на всех стадиях разработки системы в соответствии с действующими ГОСТами:

- ГОСТ 19.101-77 ЕСПД. Описание программы;

- ГОСТ 19.502-78 ЕСПД. Описание применения;

- ГОСТ 19.504-79 ЕСПД. Руководство программиста;

- ГОСТ 19.505-79 ЕСПД. Руководство оператора;

- ГОСТ 19.502-78 ЕСПД. Пояснительная записка

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

2.2.9 Источники разработки

Источником разработки является информация, полученная разработчиком в ходе исследования предприятия заказчика при прохождении преддипломной практики.

Вспомогательными источниками явилась литература: учебники по программированию в MicrosoftVisualBasic, материалы Интернет – сайтов, освещающих деятельность аналогичных предприятий, периодические издания по медиапланированию.

2.3 Модели деятельности предприятия

Функциональная модель деятельности предприятия и диаграмма декомпозиции функциональной модели деятельности предприятия разработаны при помощи CASE- средства BPWin.

Начальная контекстная диаграмма приведена на рисунке 2.1:

Рисунок 2.1 – Начальная контекстная диаграмма функциональной модели деятельности предприятия

Основными бизнес-процессами деятельности предприятия являются:

- оформление договоров на изготовление или обработку видеоматериала;

- изготовление или обработка видеоматериала;

- разработка медиаплана (подготовка расписания выхода видеороликов на трансляцию);

- непосредственно видеотрансляция рекламы на светодиодном экране.

Основные бизнес-процессы деятельности предприятия представлены на рисунке 2.2:

Рисунок 2.2 – Диаграмма декомпозиции функциональной модели деятельности предприятия AS - IS

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

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

На рисунке 2.3 представлена DFD диаграмма разработки медиаплана, выполненная при помощи CASE – средства BPWin.


Рисунок 2.3 - Сценарий разработки медиаплана

2.4 Информационно-логическая модель системы

На этапе "Инфологического проектирования" выполняется построение информационно-логической или инфологической модели (ИЛМ) предметной области, называемой также концептуальной моделью.

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

При построении ИЛМ используются такие термины, как объекты, свойства и отношения.

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

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

Связь - это соответствие или отображение между элементами двух или более множеств.

Существует связь между объектами его свойствами, а также между различными классами объектов.

Различают следующие типы связей:

- 1:1 - один к одному;

- 1:M - один ко многим;

- M:1 - многие к одному;

- N:M - многие ко многим.

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

Каждый из этих объектов имеет свои свойства и связи с другими объектами.

Атрибутами объекта «Заказчик» являются:

- код организации;

- наименование организации;

- ответственное лицо;

- ИНН;

- адрес организации и т.д.

Атрибутами объекта «Договор» являются:

- номер договора;

- дата заключения договора.

Атрибутами объекта «Видеоролик» являются:

- код видеоролика;

- имя ролика;

- хронометраж видеоролика;

- цена изготовления или доработки видеоролика и т.д.

На рисунке 2.4 представлена E-R диаграмма (Entity-Relation, сущность-связь) процесса медиапланирования.

Рисунок 2.4 – Инфологическая модель предметной области

2.5 Применение объектно-ориентированного подхода

Объектно-ориентированный подход моделирования данных обусловлен выбором среды реализации программного обеспечения: в данном случае это VisualBasic 6.

Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами [5].

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

Основные понятия объектно-ориентированного подхода — объект и класс. Объект определяется как осязаемая реальность (tangibleentity) - предмет или явление, имеющее четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс.Класс — это множество объектов, связанных общностью структуры и поведения. Любой объект является экземпляром класса.

Диаграмма классов определяет типы объектов системы и статические связи между ними. Для настоящего проекта построение диаграммы классов должно рассматриваться в аспекте реализации: модель предметной области определяет реализацию классов программного обеспечения. Диаграмма классов приведена в Приложении Г.

Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования [6]:

- диаграммы вариантов использования (usecasediagrams) - для моделирования бизнес-процессов организации (требований к системе);

- диаграммы классов (classdiagrams) — для моделирования статической структуры классов системы и связей между ними;

- диаграммы поведения системы (behaviordiagrams);

- диаграммы взаимодействия (interactiondiagrams) - для моделирования процесса обмена сообщениями между объектами. Существуют два вида диаграмм взаимодействия: диаграммы последовательности и кооперативные диаграммы;

- диаграммы состояний (statechartdiagrams) — для моделирования поведения объектов системы при переходе из одного состояния в другое;

- диаграммы деятельностей (activitydiagrams) — для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей;

- диаграммы реализации (implementationdiagrams):

1) диаграммы компонентов (componentdiagrams) — для моделирования иерархии компонентов (подсистем) системы;

2) диаграммы размещения (deploymentdiagrams) — для моделирования физической архитектуры системы.

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