3.2. Методика проектирования арм
3.2.1. Организационный аспект
В реальном проектировании информационных систем принимают участие, как минимум, две стороны — Заказчик и Исполнитель.
В роли Заказчика при проектировании выступают администратор предметной области, администраторы фрагментов предметной области, руководители функциональных подсистем разрабатываемой автоматизированной системы, т.е. лица, компетентные и полномочные принимать решения, которые могут оказать влияние на саму предметную область. Кроме того, Заказчик представляет интересы конечных пользователей.
Заказчик несет ответственность за информацию, которую он передает проектировщику системы. Заказчик формулирует задачу проектирования, утверждает техническое задание на проектирование, принимает (или не принимает), оплачивает (или не оплачивает) работу Исполнителя.
В нашем случае процесс проектирования имеет учебный характер. В роли Заказчика выступает Преподаватель, который сформулировал ряд задач проектирования в том виде, как это изложено в разделах 1.3 и 2.2.
Исполнитель — это обычно группа из нескольких специалистов-проектировщиков с руководителем во главе. Если руководитель проекта не обладает достаточным опытом выполнения подобных работ в данной предметной области, ему необходим консультант, который разъясняет особенности предметной области, подсказывает альтернативные варианты, помогает обнаружить сильные и слабые стороны обсуждаемых проектных решений. Разработка проекта, выполняемая несколькими специалистами, позволяет в силу разнообразия их опыта всесторонне обсудить их проект системы. Однако окончательные решения принимает руководитель проекта (в ходе работы над проектом и на этапе его внедрения он же выполняет роль администратора БД).
Наконец, в группе должен быть технический работник, который ведет документацию разрабатываемого проекта. На стадии физической реализации в его функции входит также управление коллективным использованием БД при разработке и отладке приложений.
В нашем случае Исполнителем Практикума является бригада студентов, а Исполнителем курсового проекта — один студент. Главная задача Исполнителя — получить практический опыт проектирования информационных систем и подтвердить это демонстрацией работоспособности созданных АРМ при защите Практикума и курсового проекта.
Реальное проектирование, как известно, складывается из целого ряда более или менее стандартных стадий, конкретное содержание которых в значительной степени зависит от предметной области. В нашем учебном случае представляется целесообразным ограничить процесс проектирования следующими стадиями:
предпроектное исследование, завершающееся разработкой технического задания (ТЗ);
техническое проектирование, заключающееся, прежде всего, в разработке информационной структуры БД и технологии работы с ней:
рабочее проектирование — разработка программного обеспечения, контрольных примеров и всей необходимой документации, оформленной в виде отчета.
3.2.2. Разработка технического задания
Итак, Вы имеете задачу проектирования (вариант задания из разд. 1.3 или 2.2). Формулировки задач предусматривают разработку АРМ для определенных почтовых технологических операций или процессов, то есть в какой-то степени обозначают предметную область проектирования. И это все.
С чего же следует начать решение этой задачи?
Прежде всего, полезно прояснить для себя, что именно представляет собой объект проектирования.
В нашем случае это АРМ — некий информационно-программно-технический объект, предназначенный для автоматизации определенных технологических операций или процессов.
Техническая составляющаяэтого объекта проектированию не подлежит, а лишь учитывается при проектировании, она задана. Это персональный компьютер, имеющийся в распоряжении бригады студентов.
Информационная составляющаяво всех вариантах — это массив структурированной информации на машинном носителе, относящейся к соответствующей предметной области, позволяющий производить запись, хранение, редактирование, выборку каких-либо сведений по запросу, то есть база данных.
Программная составляющая— программа или набор программ, позволяющих пользователю АРМ манипулировать данными, хранящимися в базе данных, с помощью соответствующего пользовательского интерфейса.
Таким образом, проектированию подлежат информационная и программная составляющие объекта, который называется АРМ.
Однако варианты заданий не содержат конкретного описания того, что именно представляет собой то или иное автоматизированное рабочее место и каковы его функции. Поэтому Исполнитель должен выработать собственное представление о конечном результате проектирования и довести его до сведения Заказчика. Если Заказчик согласится с предложениями Исполнителя и, в свою очередь, сформулирует собственные требования, с которыми согласится Исполнитель, то результат таких взаимных соглашений и будет представлять собой техническое задание на проектирование.
Этот документ должен так конкретизировать, уточнить и ограничить задачу проектирования, сформулированную Заказчиком, чтобы мог устранить все неоднозначности взаимопонимания между Заказчиком и Исполнителем и послужить необходимым и достаточным основанием для успешного выполнения последующих стадий проектирования.
Для того, чтобы сформулировать техническое задание на разработку АРМ Исполнитель должен сформировать собственное представление о его возможных целях и функциях. Для этого и требуется проведение предпроектных исследований предметной области.
В нашем случае предметной областью или предметом автоматизации, для которого создается АРМ, является технологический процесс, состоящий из неких событий, действий его участников над материальными и информационными объектами. Для дальнейшей работы проектировщику потребуется иметь такое описание этого процесса, которое будет содержать не только набор необходимых количественных параметров, но и позволит проследить динамику происходящего, развитие событий и действий во времени, все изменения происходящие с объектами. Это описание процесса в текстовой форме с поясняющими рисунками назовем модельюилисценарием.
Понятно, что начать следует с составления модели неавтоматизированного процесса (операции) «как есть», для чего проектировщику потребуется изучить Почтовые правила и другую доступную документацию. В результате он должен добиться полной ясности во всех аспектах изучаемой технологической операции или процесса. Может случиться так, что изучение имеющихся материалов не даст полной картины того, что должно происходить. В реальном проектировании в подобных случаях проектировщик прибегает к помощи консультантов, экспертов — специалистов в данной предметной области. В нашем учебном случае будем считать, что Исполнитель сам является таким специалистом и способен дать собственные ответы на все возникающие вопросы.
Модель неавтоматизированного процесса (операции) следует использовать для принятия решений о том, что именно в этом процессе будет автоматизировано с использованием АРМ, а что не будет. К моменту принятия подобных решений Исполнитель должен располагать определенной суммой знаний о возможностях и ограничениях средств, которыми он располагает для создания АРМ (персональный компьютер, MS Access, MS Visual Basic).
Использование АРМ в технологическом процессе (операции) неизбежно вносит изменения в этот процесс и способно как упростить, так и усложнить его. Фактически, несмотря на то, что это формально не является задачей проектирования, мы создаем новую технологию. Это нужно иметь в виду. Естественно, следует принимать такие решения, которые, по крайней мере, умозрительно, способствуют росту производительности труда.
Все предложения Исполнителя о введении элементов автоматизации в существующую почтовую технологию целесообразно отразить, преобразовав модель неавтоматизированного процесса «как есть» в модель автоматизированного процесса «как надо». Модель должна помочь проектировщику рассмотреть АРМ как объект, реализующий определенный набор функций, находящийся во взаимосвязях с внешней средой и пользователями, и не упустить ни каких важных особенностей этих взаимосвязей.
На рис. 3.2.2 показан типичный вариант среды функционирования почтового АРМ. Выявление характера и динамики взаимосвязей АРМ с остальными элементами этой среды собственно и является целью составления сценария автоматизированного технологического процесса (операции).
Из рисунка видно, что в автоматизированном технологическом процессе могут принимать участие несколько действующих лиц, все или часть которых являются пользователями АРМ. Типичными пользователями почтового АРМ являются:
администратор БД, он же Исполнитель проекта;
администратор функциональной подсистемы — обычно это Начальник производственного участка;
конечные пользователи — операторы производственного участка или клиенты почтовой связи.
Пользователи АРМ различаются по уровню компетенции, характеризующему возможность доступа к тем или иным данным. Речь идет о защите определенной части данных от тех пользователей, которые по различным причинам не должны иметь возможность их получения или изменения. Следовательно, БД должна иметь специальные средства для обеспечения санкционированного доступа пользователей к данным.
Рис.
3.2.2.
