71
Наименование показателей
Идентификатор показателя
Стоимость i-того мероприятия
Si
Длительность показа j-той позиции
Dj
Количество использования
мероприятия i-того типа в j-том
маркетинговом исследовании
Km
Таблица 2.4
Формализованное описание результатных показателей
Наименование
показателя
Идентификатор
показателя
Алгоритм расчета
Стоимость вида
мероприятий в
маркетинговом
исследовании
SSj
Si*Dj
Общий бюджет
маркетингового
исследования
Bj
ΣSSj
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
Управление информационной системой происходит посредством выбора
пункта меню или подменю, каждому пункту меню соответствует
индивидуальная функция. На рисунке 2.2 представлено дерево функций
административной части информационной системы. На рисунке 2.3
представлено дерево функций клиентской части информационной системы.
72
Функции
администратора
СлужебныеОсновные
Настройка
справочников
Настройка данных
доступа
Определение типа
статей
Добавление
бюджета
Получение
отчетов
Статьи
расходов
Расходы
Маркетингов
ые
исследовани
я
Работа со
справочниками
Рисунок 2.2 Функции администратора
Администратор может управлять работой системы анализа бюджета, в том
числе вводить настройки, заполнять справочники, следить за оформлением
статей, определять дополнительную информацию и параметры авторизации.
Диалогом называется процесс обмена данными между пользователем и
ПО, реализуемый посредством интерактивного терминала при условии
выполнения нескольких правил [12]. Общение ПК и пользователя в процессе
работы с ИС создано на базе диалогового режима, который контролирует сама
программа.
Интерфейс пользователя создается по технологии WIMP (Window – окно,
Image – картинка, Menu – меню, Pointer - указатель). Тут могут применятся и
элементы графического интерфейса: окна диалогов и приложений, контекстное и
иерархическое меню, средства вывода и ввода данных, значки панели
73
инструментов, программные указатели и т.п. Такие графические элементы
выполняют как служебные, так и базовые программные функции.
Сценарий диалога является структурной схемы, где в виде дерева
отражены действия пользователя в процессе взаимодействия с отдельной
формой и описаны функциональные возможности панели инструментов. Любая
форма включает иерархическое меню, которое отражает все права пользователя
в процессе работы с конкретной формой.
Функции
пользователя
СлужебныеОсновные
Настройка данных
доступа
Анализ
бюджета
Добавление
фактического бюджета
Добавление расходов
Добавление
количества
Подсчет общей суммы
Добавление расходов
Добавление
количества
Подсчет общей суммы
Анализ экономии
Анализ перерасхода
Анализ выполнения
бюджета
Добавление
планируемого
бюджета
Рисунок 2.3 Дерево функций пользователя системы
На основе состава функций и их иерархии разрабатывается сценарий
диалога пользователя с системой, представленные на рисунках. 2.4 и 2.5.
74
Сценарий работы
администратора
Авторизация
Выбор пункта меню
Справочнкии
Расходы
Группы статей
расходов
МИ
Бюджеты
Пользователи
Добавить
Планируемый
Фактический
Анализ
Выход
Удалить
Рисунок 2.4 Сценарий диалога системы и администратора
Сценарий работы
пользователя
Авторизация
Выбор пункта меню
Справочнкии
Расходы
Группы статей
расходов
МИ
Бюджеты
Планируемый
Фактический
Анализ
Выход
Рисунок 2.5 Сценарий диалога пользователя
75
2.3.2 Характеристика базы данных
Инфологическая (концептуальная) модель — это некое описание
предметной области, выполненное без привязки в дальнейшем к конкретным
программным и техническим средствам. Инфологическая модель является
динамической и имеет легкую корректировку. К основным требованиям,
предъявляемым к инфологической модели, часто относят такие:
• инфологическая модель может содержать всю необходимую и
достаточную информацию для дальнейшего создания БД;
• инфологическая модель должная пониматься лицам, которые
непосредственно участвуют в создании системы.
ER-модель является логической структурой данных об объектах системы.
Компонентами ER-модели выступают сущности (объекты) и отношения (связи
между объектами). Объект включает большое количество реализаций или
экземпляров. Экземпляр объекта происходит из совокупности конкретных
значений реквизитов и определяется однозначно, т.е. указываться значением
ключа объекта, включающего нескольких ключевых реквизитов.
Для отображения отношений между сущностями часто применяют связи.
Связи могут быть, если экземпляры сущностей взаимосвязаны логически уже
изначально.
Сущность изображается в виде прямоугольника, вверху которого
располагается имя сущности. В прямоугольнике могут быть перечислены
атрибуты сущности; атрибуты ER-диаграмм, набранные полужирным шрифтом,
являются ключевыми. ER-диаграмма базы данных разработанной
информационной системы приведена на рис. 2.6.
76
Сотрудники
PK idsotr
name
dolg
login
parol
dates
surname
datebor
udal
Статьи расходов
PK ido
nameob
udalo
Бюджет фактический
PK idchet
idklientchet
idprodchet
kolvochet
datechet
nomer
Бюджет планируемый
PK idchet
idklientchet
idprodchet
kolvochet
datechet
nomer
Расходы
PK idprod
nameprod
art
idvz
idtz
model
prise
primP
udalPr
optst
rozst
edizmpr
Рисунок 2.6ER-диаграмма базы данных
В таблицах ниже приведена характеристика реквизитов таблиц базы данных.
Таблица 2.4
Структура таблицы Бюджет планируемый
Поле
Тип
Описание
поля
Null
По умолчанию
idchet
int(11)
Код записи
Нет
idklientchet
int(11)
Код
бюджета
Нет
idprodchet
int(11)
Код статьи
Нет
kolvochet
int(11)
Количество
Нет
datechet
text
Дата
Нет
nomer
int(11)
Номер
Нет
Таблица 2.5
Структура таблицы Бюджет фактический
Поле
Тип
Описание
поля
Null
По умолчанию
idchet
int(11)
Код записи
Нет
77
idklientchet
int(11)
Код
бюджета
Нет
idprodchet
int(11)
Код статьи
Нет
kolvochet
int(11)
Количество
Нет
datechet
text
Дата
Нет
nomer
int(11)
Номер
Нет
Таблица 2.6
Структура таблицы Статьи расходов
Поле
Тип
Описание
поля
Null
По умолчанию
iddolg
int(11)
Код записи
Нет
namedolg
varchar(45)
Наименование
Да
NULL
udald
int(1)
Флаг удаления
Нет
0
Таблица 2.7
Структура таблицы Расходы
Поле
Тип
Описание
поля
Null
По умолчанию
idprod
int(11)
Код записи
Нет
nameprod
text
Наименование
Да
NULL
art
varchar(45)
описание
Да
NULL
idvz
int(11)
Код типа
Да
NULL
idtz
int(11)
Код типа
Да
NULL
model
varchar(255)
ставка
Да
NULL
prise
varchar(45)
Стоимость
Да
NULL
primP
text
Примечание
Да
NULL
udalPr
int(1)
Флаг удаления
Нет
edizmpr
varchar(255)
Единица
измерения
Нет
78
Таблица 2.8
Структура таблицы Сотрудники
Поле
Тип
Описание
поля
Null
По умолчанию
idsotr
int(11)
Код записи
Нет
name
varchar(45)
Фамилия
Да
NULL
dolg
varchar(45)
Должность
Да
NULL
login
varchar(45)
Логин
Да
NULL
parol
varchar(45)
Пароль
Да
NULL
dates
timestamp
Дата
регистрации
Нет
CURRENT_TIMESTAMP
surname
varchar(45)
имя,
отчество
Да
NULL
datebor
varchar(45)
Дата
рождения
Да
NULL
udal
int(1)
Флаг
удаления
Нет
2.3.3 Структурная схема пакета (дерево вызова программных
модулей)
Структурная схема пакета представлена на рисунке 2.7.
79
ПМ авторизация
ПМ Главное меню
ПМ Анализ
бюджета
ПМ
фактического бюджета
ПМ Добавление
расходов
ПМ Добавление
количества
ПМ Подсчет общей
суммы
ПМ Добавление
расходов
ПМ Добавление
количества
ПМ Подсчет общей
суммы
ПМ Анализ экономии
ПМ Анализ
перерасхода
ПМ Анализ
выполнения бюджета
ПМ планируемого
бюджета
Рисунок 2.7 Структурная схема пакета
2.3.4 Описание программных модулей
Программирование является процессом создания программы, и при
классической ручной разработке ПП без привязки к методу проектирования
может представляться как череда следующих шагов:
• Выявление требований к ПО;
80
• Выбор или создание алгоритма решения поставленной задачи;
• Подготовка команд;
• Проверка;
• Тестовые запуски.
Выявление требований к ПО – важный этап, где подробно указывается
начальная информация и составляются требования к итогу работы. Также
определяется поведение программы в разных случаях.
В процессе выбора или создания алгоритма важно определить череду
действий, необходимых для достижения результата. Многие задачи часто
решаются различными способами. В этом случае разработчик, применяя
отдельный критерий, к примеру, быстроту работы алгоритма или его точность,
находит оптимальное решение. Далее происходит подробное описание
алгоритма. По факту выделения требований к программе и подготовки
алгоритма решения, его записывают на подходящем языке программирования.
Проверка ПО заключено в нахождении и корректировке ошибок, которые
были совершены на этапах подготовки задачи для реализации на ЭВМ.
Ошибки делят на синтаксические и семантические.
Синтаксические ошибки, связанные с неправильным написание
операторов языка программирования, находятся на этапе трансляции
программы. Тут даже можно увидеть сообщение, описывающее оператор, в
котором допущена ошибка, место, где она обнаружена, а также текст,
поясняющий суть проблемы.
Семантические ошибки, связанные, зачастую, с неправильным
построением математической модели и алгоритма выполнения задачи, при
процедуре прохода программы сразу не обнаруживаются, поскольку программа
выполняется и даже выдает итоговый результат.
Для сверки корректности программы выполняется ее тестирование, т.е. ее
реализация при таких исходных данных, для которых итоги решения уже
известны. При подборе тестовых наборов исходных данных важно учесть
доступность проверки разных вариантов решения задачи. Оценка корректности
программы реализуется методом сравнения результатов, полученных при
реализации программы, с имеющимися тестовыми.