Выходной материальный поток

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

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

Роль администратора БД.

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

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

Роль администратора функциональной подсистемы.

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

В нашем случае для всех вариантов АРМ в число таких функций следует отнести:

• управление данными, необходимыми для авторизации операторов;

• учет рабочего времени, выработки и качества работы операторов и получение соответствующих отчетов;

• осуществление специфических запросов;

• ввод в базу данных определенных видов информации (например, данных о тарифах).

Роль конечных пользователей.

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

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

Общим требованием для разработки моделей «как есть» и «как надо» в практикуме и дипломном проектировании является использование методологий и стандартов IDEF0 и IDEF3. В качестве инструментария для работы с графикой допустимо использование MicrosoftWordили Microsoft Visio.

Отметим, что до сих пор мы говорили о моделях или сценариях технологического процесса (операции). Однако напомним, что целью рассматриваемой стадии проектирования является разработка технического задания на АРМ, которое будет представлять собой лишь новый компонент этого процесса.

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

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

Общее представление.Производственные или коммерческие цели организации или ее подразделения и роль объекта проектирования в реализации этих целей.

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

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

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

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

Разработка технического задания завершается его утверждением Заказчиком. Если в ходе дальнейшей работы, выяснится, что ТЗ требует уточнения, то это можно сделать, но только с согласия Заказчика.