102104 (590526), страница 7

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 7)

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

Итак, в соответствие с проектируемой АСУ, процесс предоставления услуги начинается с регистрации заявки клиента в Журнале заявок АСУ (сфера ответственности и доступ – руководители клиентских отделов), факторы влияния – сформированный необходимый каталог объектов от Департамента Эксплуатации и внешняя конъюнктура рынка, на последний фактор Департамент Аренды не может оказывать влияние, но должен его учитывать при формировании предложения.

Сотрудники, ежедневно просматривая Журнал заявок, отбирают новых клиентов, закрепленных за ними. Формирование предложения идет на основании прайс-листа Департамента Аренды, который формируется в АСУ по категориям объектов и предлагается для изучения непосредственно клиенту.

Далее, клиент выбирает наиболее подходящий ему объект (объекты), основная задача операционного сотрудника на данном этапе это проставить отметку о процессе взаимодействия в Журнале клиентов (см. табл. 8 описание поля «отметка») и организовать непосредственный просмотр выбранного объекта (объектов).

После того, как клиент определил необходимый ему объект и готов заключить сделку, ответственный операционный сотрудник проставляет необходимые отметки в АСУ, как в Журнале клиентов, так и в Объектах (см. табл. 8 и 9 описание полей «отметка»), кроме этого, ответственный сотрудник предоставляет клиенту пакет документов по сделке, в соответствие с правилами заключения сделок и условиями договора клиенту выставляется счет или счет-фактура на оплату услуг Департамента Аренды, при этом также проставляются необходимые отметки в АСУ.

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

3.2 Разработка интерфейса пользовательской части

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

Разработка пользовательского интерфейса (ПИ) ведется параллельно разработке архитектуры Автоматизированной Системы Управления документооборотом и разработке баз данных в целом и в основном предшествует её имплементации. Процесс разработки ПИ разбивается на этапы жизненного цикла²⁶:

1. Анализ трудовой деятельности пользователя, объединение бизнес-функций в роли.

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

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

4. Разработка обобщенного сценария взаимодействия пользователя с программным модулем (функциональной модели) и его предварительная оценка пользователями и Заказчиком.

5. Корректировка и детализация сценария взаимодействия, выбор и дополнение стандарта (руководства) для построения прототипа.

6. Разработка макетов и прототипов ПИ и их оценка в деловой игре, выбор окончательного варианта.

7. Имплементация ПИ, создание тестовой версии.

8. Разработка средств поддержки пользователя (пользовательские словари, подсказки, сообщения, помощь и пр.) и их встраивание в АСУ.

9. Usability тестирование тестовой версии ПИ по набору раннее определенных показателей.

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

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

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

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

Перед началом разработки пользовательского интерфейса проектируемой АСУ были получены ответы на следующее вопросы:

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

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

• Какие решения пользователю необходимо принимать в процессе работы с АСУ? (в данной части решения строятся как по стратегическому планированию, так и по оперативному планированию – рядовые сотрудники принимают только оперативные решения текущего характера, руководители клиентских отделов принимают как оперативные, так и стратегические решения);

• Может ли пользователь совершать несколько различных действий одновременно? (в данной части необходимо отметить, что проектируемая АСУ дает возможность решать несколько задач одновременно, следовательно, ответ на данный вопрос – положительный);

• Какие типовые операции использует пользователь при решении задачи? (типовые операции перечислены в п. 3.1. при проектировании таблиц баз данных).

Дизайн пользовательского интерфейса должен обеспечивать минимизацию усилий пользователя при выполнении работы и приводить к²⁸:

• сокращению длительности операций чтения, редактирования и поиска информации,

• уменьшению времени навигации и выбора команды,

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

• увеличению длительности устойчивой работы пользователя и др.

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

Требования к удобству и комфортности интерфейса возрастают с увеличением сложности работ и ответственности пользователя за конечный результат. Высокая удовлетворенность от работы достигается в случае²⁹:

• Прозрачной для пользователя навигации и целевой ориентации в программе.

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

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

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

Удобный интерфейс помогает пользователю справиться с усталостью и напряжением при работе в условиях высокой ответственности за результат, поэтому основные принципы создания интерфейса пользовательской части базируются на следующих условиях³⁰:

• Совместное наращивание функциональности: возможность развивать проектируемую АСУ без разрушения (т.е. оставаясь в рамках) существующего интерфейса.

• Масштабируемость: возможность легко настраивать и расширять как интерфейс, так и собственно проектируемую АСУ при увеличении числа пользователей, рабочих мест, объема и характеристик данных.

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

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

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

В соответствие с заявленными выше принципами, требованиями и условиями, интерфейс пользовательской части АСУ Департамента Аренды разрабатывался в среде Borland С++ Builder 6. Структура интерфейса пользовательской части представлена в приложении 6. Очевидно, что в структуре интерфейса проектируемой АСУ реализованы справочники и собственно отчеты. При этом очевидно, что в справочнике «Экспозиция» имеется только опция просмотра, иных опций не предусмотрено, т.к. любые изменения в этом справочнике приведут к изменениям в других справочниках, что может вызвать нарушение объективности и релевантности данных.

В справочниках «Журнал», «Объекты», «Операции» предусмотрены возможности редактирования и правки, т.к. это необходимо для описания функциональных процессов в проектируемой АСУ.

Для того чтобы начать работу с АСУ Департамента аренды, необходимо запустить находящийся на рабочем столе файл ASU_DA.exe, после чего загрузиться основная форма системы, которая выглядит так, как представлено в приложении 7.

На основной форме находятся 5 основных пунктов меню: «Журнал», «Объекты», «Операции», «Экспозиция», «Выход».

Пункты меню «Журнал», «Объекты», «Операции», как уже было показано выше, содержат 4 подпункта, вызываемые через контекстное меню (правая кнопка мыши):

• Просмотр,

• Правка,

• Добавить,

• Удалить.

При выборе пункта «Журнал», откроется форма, которая имеет вид, представленный в приложении 8. В левой части расположены данные о клиентах Департамента Аренды: Наименование клиента и Идентификатор клиента согласно уникальному номеру клиента в базе. В правой части расположены данные по параметрам заявка клиента (требуемая категория объекта и цена), а также данные об ответственном лице, которое закреплено для взаимодействия с этим клиентом.

При выборе пункта меню «Объекты», откроется форма, представленная в приложении 9. В левой части расположены данные об объектах Департамента Аренды: Наименование объекта и Идентификатор объекта согласно уникальному номеру объекта в базе. В правой части расположены данные по параметрам указанного объекта, а также данные об ответственном лице, которое закреплено за указанным объектом.

При выборе пункта меню «Операции» имеется возможность просмотреть все операции, осуществленные как с клиентами, так и с объектами за определенный период (приложение 10 и приложение 11). Задача пункта меню «Операции» предоставлять детализированные отчеты по операциям, согласно условиям отбора, заданным пользователем.

Характеристики

Список файлов ВКР