Проектирование иерархического меню
ПРОЕКТИРОВАНИЕ
ИНФОРМАЦИОННЫХ СИСТЕМ
Методические указания
к практическим занятиям
Специальность 080801.65 – Прикладная информатика
Тема 1. Показатели экономической эффективности ИС и качества информации.
Статические показатели экономической эффективности. Динамические показатели экономической эффективности. Преимущества показателя чистой приведенной стоимости. Показатели качества информации: полнота, своевременность, достоверность, точность, форма представления.
Тема 2. Расчет ожидаемой экономической эффективности проектируемой ИС.
Расчет ожидаемой экономической эффективности проектируемой ИС на предпроектной стадии и в техническом проекте. Расчет фактической экономической эффективности. Расчет совокупной стоимости владения.
Пример расчета ожидаемой экономической эффективности коммерческого Web-сайта.
Услуга коммерческого Web-сайта состоит в предоставлении информации и выполнении расчетов по параметрам, задаваемым пользователем. Функционирование коммерческого Web-сайта связано как с капитальными (единовременными) затратами, так и с эксплуатационными (переменными) и условно-постоянными затратами. Выручка от реализации услуг по предоставлению информационной поддержки с использованием коммерческого Web-сайта определяется как произведение количества обращений пользователей на тариф за одно обращение. Аналогично определяются переменные эксплуатационные издержки с использованием показателя удельных издержек (в расчете на одно обращение).
|
|
|
Исходные данные и результаты расчета представлены в таблице 1.
Тема 3. Оценка научно-технического уровня ИС и её конкурентоспособности на рынке продукции производственно-технического назначения.
Характеристики функциональной части информационной системы. Оценка научно-технического уровня обеспечивающих подсистем. Основные характеристики организационного, технического, программного, информационного и лингвистического обеспечения. Расчет интегрального показателя научно-технического уровня.
Таблица 1.
Расчет экономической эффективности
коммерческого Web – сайта
| Наименование показателя | Обозначения | Единицы измерения | Значение |
| Капитальные (единовременные) затраты на создание коммерческого Web – сайта | К | т.р. | 1000 |
| Норма прибыли на капитал (годовая процентная ставка) | Е | 1/год | 0,15 |
| Цена (тариф) за услугу, состоящую в однократном обращении пользователя к коммерческому Web – сайту | Ц | р./обр. | 100 |
| Удельные издержки (в расчете на одно обращение) | S уд | р./обр. | 20 |
| Годовые условно-постоянные издержки, то есть издержки, не зависящие от количества обращений к коммерческому Web – сайту | С у-п | т.р./год | 120 |
| Количество обращений к коммерческому Web- сайту в течение года | N | раз | 30000 |
| Выручка от реализации услуг по предоставлению информационной поддержки с использованием коммерческого Web – сайта | B | т.р./год | 3000 |
| Эксплуатационные затраты на содержание коммерческого Web – сайта | C | т.р./год | 720 |
| Годовая бухгалтерская прибыль | Э год | т.р./год | 2280 |
| Годовой экономический эффект | Э | т.р./год | 2130 |
| Срок окупаемости | Т ок | мес. | 5 |
Тема 4. Стадии и этапы процесса проектирования ИС.
|
|
|
Этапы предпроектной стадии: формирование требований к автоматизированной системе, разработка концепции автоматизированной системы и техническое задание. Этапы предпроектной стадии: эскизный проект, технический проект и рабочая документация. Послепроектная стадия: ввод в действие, сопровождение ИС. Содержание этапов.
Тема 5. Анализ проектной документации ИС, выполненный ведущими организациями.
Примеры проектной документации и оценка их соответствия предъявляемым требованиям. Анализ требований ГОСТ 34.601–90 «Информационная технология. Комплекс стандартов на автоматизированные системы», ГОСТ Р ИСО/МЭК 12207–99 «Информационная технология. Процессы жизненного цикла программных средств».
|
|
|
Тема 6. Разработка технических заданий на создание информационной системы и ее элементов.
Разработка технического задания на создание информационной системы в соответствии со следующей структурой:
1. Наименование работы (разработка комплекса задач ИСЭ);
2. Наименование организации-заказчика;
3. Наименование организации-разработчика;
4. Руководитель (Ф.И.О., ученая степень, должность);
5. Код темы по УДК;
6. Сроки выполнения работы;
7. Стоимость работы;
8. Цель работы (разработка программного комплекса ИС);
9. Содержание работы (перечни функциональных задач и файлов базы данных, подлежащих проектированию);
10. Ожидаемые результаты работы (опытная эксплуатация программного комплекса);
11. Научно-техническая и практическая ценность ожидаемых результатов работы (совершенствование информационной поддержки пользователя);
12. Перечень научной, технической и другой документации, представляемый по окончании работы.
|
|
|
Анализ требований ГОСТ 34.602–89 «Техническое задание на создание автоматизированной системы».
Контрольная работа. Проводится по материалам тем 1‑6.
Данная контрольная работа предусматривает анализ АРМа управленческого персонала и рекомендации по его развитию в разрезе следующих аспектов:
1. Характеристика предприятия.
2. Назначение подразделения (отдела) предприятия, в котором функционирует анализируемый АРМ.
3. Таблица полноты информационной поддержки функций сотрудника подразделения (отдела), обеспечиваемой АРМом (таблица 2).
Таблица 2.
Таблица полноты информационной поддержки функций
сотрудника подразделения (отдела), обеспечиваемой АРМом
| Функции сотрудника подразделения | Характеристика существующей информационной поддержки, обеспечиваемой АРМом (отсутствует, присутствует, степень соответствия, качество поддержки и т.п.) |
| 1. | |
| 2. | |
| и т.д. |
4. Предложения студента по расширению функциональности АРМа и повышению качества функциональной поддержки (перечень новых функциональных задач).
5. Описание постановки этих задач (описание входной информации, включая хранящуюся в базе данных, выходной информации, принципиальный алгоритм решения задачи, содержащий математические формулы и логику обработки информации).
6. Таблица соответствия функциональных задач и файлов базы данных (таблица 3).
7. Техническое задание на проектирование.
Тема 7.Построение информационных моделей и анализ результатов обследования объекта создания ИС.
Построение плоских информационных моделей в графовой форме, в виде информационно-технологических схем, в матричной форме («подразделение на подразделение», «документ на документ») и в виде операционных таблиц.
Таблица 3.
Таблица соответствия функциональных задач и файлов базы данных
|
| Функциональные задачи | Файлы базы данных | |
| Существующие файлы | Новые файлы | ||
| Существующие задачи | |||
| Новые задачи | |||
Тема 8. Разработка постановок экономических задач промышленного предприятия.
Анализ структуры описания постановки задачи, представленной на рисунке 1.
Разработка постановок для следующих задач:
1. АРМ кладовщика;
2. АРМ менеджера по продажам;
3. АРМ менеджера по закупкам;
4. АРМ инспектора отдела кадров;
5. АРМ маркетолога;
6. АРМ сотрудника кредитного отдела банка;
7. АРМ библиотекаря.
Рис. 1. Структура описания постановки задачи
Тема 9. Проектирование пользовательского интерфейса АРМ управленческого персонала.
Пользовательский интерфейс (User Interface – UI) включает в себя: меню, экранные формы и отчеты.
При проектировании пользовательского интерфейса любой программы должны выполняться следующие эвристические правила[1]:
· Видимость состояния системы (правило обратной связи). Программа (система) должна всегда информировать пользователя о состоянии своей работы. При рассмотрении этого правила необходимо учитывать несколько аспектов:
- информированность пользователя.Пользователь всегда должен иметь информацию о текущем статусе работы программы – например, сколько времени прошло от начала процесса копирования файлов. Кроме этого, пользователь обязательно должен видеть, к чему привело любое его действие: ввод данных, нажатие кнопки и т.п.;
- средства обеспечения обратной связи.Выбор конкретного средства обратной связи зависит от типа информации, которую нужно донести до пользователя, а также типа действия, которое вызывает потребность в обратной связи. Информация, при рассмотрении данного вопроса, делится на типы в зависимости от ее назначения и степени важности. Например, сообщения о критических ошибках, приводящих к невозможности продолжения работы, обычно выводятся в отдельном диалоговом окне. При этом работа приложения останавливается до тех пор, пока пользователь не закроет окно с информацией об ошибке (так называемое модальное окно), а сообщения о незначительных ошибках – в статусной строке окна приложения без остановки его работы. Что касается зависимости выбора средства обратной связи от типа действия, вызывающего его, то традиционно считается, что если пользователь сделал какое-то действие – например, запустил процесс кодирования файла и ожидает какого-то результата, то этот результат (или сообщение об ошибке) должен быть выведен в отдельном окне. Если же результат, о котором требуется сообщить пользователю, является текущей информацией о процессе, и не является прямым следствием действий пользователя, то можно ограничиться отображением соответствующего сообщения в строке состояния. Текстовые сообщения, выводящиеся в окне программы, для организации обратной связи могут быть дополнены другими средствами оповещения пользователя, например звуком;
- время оповещения.Промежуток времени от совершения пользователем действия до получения им информации о реакции на это действие (или о событии, вызванном этим действием) должен быть минимальным, поскольку наличие или отсутствие у пользователя информации о текущем состоянии системы определяет дальнейшие действия пользователя. Если пользователь не будет знать, что последняя операция была завершена неудачно, то последующие его действия могут выполняться с ошибками.
· Равенство между системой и реальным миром.Программа (система) должна «общаться» с пользователем на его языке. В данном случае подразумевается использование понятий, образов и концепций, которые знакомы пользователю по реальному миру и к которым он уже привык. Представление информации и объектов в программе должно быть организовано в естественном и логичном порядке.
· Свобода действий пользователя.Пользователь должен иметь контроль над системой и возможность изменить текущее состояние программы. Чаще всего это реализуется в виде кнопки Cancel (Отмена), расположенной в диалоговом окне и позволяющей прекратить выполнение текущей операции или закрыть это диалоговое окно. Аналогичный результат дает нажатие на клавиатуре клавиши <Escape>. Еще одним средством выхода из ошибочной ситуации являются функции Undo (Отменить) и Redo (Повторить). Если же по каким-либо причинам действие, на выполнение которого дал команду пользователь, нельзя будет отменить, то на экран должно быть выведено соответствующее предупреждение, а также просьба подтвердить выполнение команды.
· Последовательность и стандарты. Принцип последовательности означает использование одних и тех же средств для выражения схожих образов и выполнения действий, имеющих одинаковую природу. Примером применения принципа последовательности и стандартизации является интерфейс «в стиле Windows».
· Предупреждение ошибок. Интерфейс, предупреждающий возникновение ошибок, называется «услужливым». Программа как бы заботится о пользователе, будучи всегда готовой предложить ему помощь, дать подсказку. Кроме того, уменьшение вероятности возникновения ошибок пользователя при работе с программой достигается тщательной проработкой всех элементов интерфейса и его концепции в целом в соответствии с правилами проектирования интерфейсов.
· Понимание лучше, чем запоминание. При проектировании интерфейса все объекты, функции, действия должны быть видимыми и легко доступными пользователю. Данное правило отражает принцип прозрачного интерфейса – интерфейса, который понятен и не заставляет пользователя удерживать в памяти информацию из одной части программы, чтобы применить ее в другой. В любой момент ему должно быть ясно, что нужно делать в данный момент. В хорошем интерфейсе инструкции по использованию программы (системы) всегда видимы или легко доступны для вызова в любое время, когда это требуется. Это может быть реализовано как в виде продуманной организации элементов интерфейса, так и непосредственно в виде подсказок пользователю.
· Гибкость и эффективность использования. При проектировании интерфейса перед разработчиком часто встает такая проблема: требуется, чтобы интерфейс был одинаково удобен и для новичков, и для опытных пользователей. Для решения этой проблемы прибегают к следующему приему: функции, которые ускоряют работу, оформляют так, что они не видны начинающим, но легко доступны продвинутым пользователям. Примером реализации универсального интерфейса – это «горячие клавиши». Обозначения «горячих клавиш» пишутся рядом с соответствующими пунктами меню, поэтому они, с одной стороны, не мешают новичкам (они могут воспользоваться мышью для выбора пункта меню или щелчка по кнопке на панели инструментов), а, с другой стороны, легко доступны опытным пользователям. Другой пример реализации «интерфейса для каждого» – возможность выполнения сложных функций программы с помощью Мастера или вручную, посредством настройки опций в соответствующем диалоговом окне. Еще одной составляющей данного правила является необходимость предоставления пользователю возможности быстрого выполнения частых действий. Это может быть реализовано, например, с помощью команды для вызова последних открывавшихся файлов, и меню, в которых сначала показываются наиболее часто выполняющиеся команды.
· Эстетичный и минималистический дизайн. Каждый элемент интерфейса (кнопка или текстовая подпись) отвлекает часть внимания пользователя. Это может привести к тому, что видимость и, соответственно, легкость восприятия пользователем действительно нужных и полезных частей интерфейса будет сильно уменьшена за счет элементов, без которых в данном случае можно было бы обойтись.
· Распознавание и исправление ошибок. Это правило определяет проектирование сообщений об ошибках. Сообщение об ошибке должно состоять из двух частей:
- описание ошибки. Оно должно быть четким, ясным и понятным, давать пользователю всю необходимую информацию о причинах и месте возникновения ошибки;
- описание решения проблемы. Большинство разработчиков программ размещают описание решения проблемы в разделе справочной системы, посвященном соответствующей ошибке. Однако лучше всего включить эту информацию прямо в диалоговое окно сообщения об ошибке, так, как это сделано, например, в системе управления базами данных Microsoft Access. При описании пути решения проблемы нужно избегать составления слишком объемных текстов, т.к. пользователи будут просто пробегать их глазами, не вникая в смысл написанного, подобно тому, как человек, просматривающий газету, сначала останавливает взгляд на коротких заметках, пропуская большие материалы. Поэтому рекомендуется составлять описание действий по исправлению ошибки наподобие пошаговой инструкции, каждый шаг которой составляет 1–2 предложения.
· Справка и документация. Меню программы (системы) должно содержать пункт, с командами Справка (Help), О программе вызывающие соответственно справочную систему и информацию о программе.
Проектирование иерархического меню
Функциональная часть информационной системы (ИС) обычно имеет иерархическую структуру, то есть содержит комплексы задач, подкомплексы и, наконец, отдельные задачи. Выбор требуемой задачи в этом случае удобно осуществлять с помощью иерархического меню.
Например, на верхнем уровне иерархии могут находиться такие комплексы задач, как:
· поддержка (формирование, ведение базы данных);
· обработка (планирование, учет, анализ и т.д.);
· справки (отчеты, ответы на запросы).
В скобках указаны подкомплексы задач. Пользователю предоставляется возможность последовательно конкретизировать выбор интересующего подкомплекса задач и, наконец, отдельной задачи, которую он собирается решать.
Порядок проектирования меню следующий:
· проектирование содержания меню;
· проектирование формы меню;
· программное обеспечение меню.
Проектирование содержания меню требует изучения предметной области обоснования состава задач, образующих функциональную часть системы, и их иерархической взаимосвязи. Для этого необходимо выяснить должностные обязанности пользователя системы, которые зависят от назначения подразделения, в котором он работает. А место и роль подразделения, в свою очередь, зависит от характеристик предприятия в целом.
Выбор пункта меню может завершаться:
· появлением на экране меню следующего уровня;
· выполнением команды (например, возврат в системное меню);
· выполнением процедуры (например, процедуры ввода или вывода информации, функциональной обработки);
· появлением «заглушки» – сообщения о том, что данный пункт еще не реализован или же другого комментария.
Пример таблицы, отражающий выбор пункта меню для АРМ кладовщика склада материалов представлен ниже (см. таблицу 4).
Таблица 4.
Содержательное проектирование иерархического меню
| Пункт главного меню Пункт подменю | Экранная форма для ввода информации | Выходная форма (отчет) |
| Помощь Приход Расход Отпуск на сторону Внутреннее перемещение Отпуск по лимитно-заборной карте Справки Наличие материала на складе Движение материалов за период Выход | – Приходный ордер Подменю Товарно-транспортная накладная Требование Лимитно-заборная карта Подменю Наличие материала на складе Движение материалов за период – | Текст инструкции Приходный ордер – Заглушка Требование Лимитно-заборная карта – Отчет о наличии материала на складе Отчет о движении материалов Системное меню |
В главном меню следует предусмотреть пункт «Выход», который позволяет вернуться к системному меню, что удобно при отладке системы.
Иерархическое меню обычно содержит главное меню в виде горизонтально расположенной линейки. Выбор пункта этого меню приводит к появлению всплывающего меню. Выбор пункта всплывающего меню может вызвать появление каскадного меню. Все меню, начиная с третьего уровня, называются каскадными. Свое название они получили потому, что располагаются на экране уступами, частично перекрывая друг друга.
Существует ряд правил, которыми следует руководствоваться при проектировании меню. Эти правила соответствуют международным стандартам по проектированию пользовательского интерфейса. Один из этих стандартов – CUA (Common User Access).
Назовем следующие рекомендации:
1. Количество уровней в меню должно быть не более 2‑3.
2. Пользователь должен знать, в какой точке иерархического меню он находится, то есть следы предшествующих уровней должны оставаться.
3. Пункты меню не нумеруются.
4. Название пунктов горизонтального меню должно быть коротким.
5. Заглавной должна быть только первая буква названия пункта.
6. Пункт меню может быть выбран по первой (выделенной) букве его названия. Если первая буква названия пункта меню не является уникальной, то можно назначить любую выделенную букву.
7. Для выбора пункта всплывающего меню может быть предназначена «горячая клавиша» (hot key), поскольку путь к нему через главное меню может быть долгим.
8. Пункты, к которым часто обращаются, должны быть расположены в начале меню. Если присутствует пункт «Помощь», то он располагается в начале главного меню, а пункт «Выход» – в конце.
9. Логически взаимосвязанные пункты всплывающего меню объединяются в группы сплошной горизонтальной линией и могут получить свои подзаголовки.
10. При оформлении меню может быть выбрана своя световая схема (color scheme). Вертикальное (всплывающее) меню может быть выделено тенью.
 |
Результат проектирования иерархического меню следует представить в графическом виде в форме дерева (рисунок 2):
1 – имя меню;
1.1; 1.2; …; 1.n – пункты меню 1-го уровня;
1.2.1; …; 1.n.i – пункты меню 2-го уровня.
Рис. 2. Представление иерархического меню в графическом виде
Проектирование экранных форм
Экранные формы в настоящее время образуют основу интерфейса в человеко-машинном диалоге.
Порядок проектирования экранной формы подразумевает следующие этапы:
· проектирование содержание экранной формы;
· проектирование ее формы представления (формы экрана);
· программное обеспечение экранной формы.
Содержание экранной формы зависит от ее назначения. По назначению можно выделить четыре класса экранных форм:
· для ввода информации в базу данных, т.е. для формирования и ведения базы данных; различают экранные формы для ввода справочной информации на этапе конфигурирования информационной системы (базовые формы) и экранные формы для ввода переменной информации;
· для ввода параметров обработки информации по задаче и идентификаторов запросов (условия выборки);
· для вывода результатов решения задачи и справочной информации;
· комбинированные экранные формы, предусматривающие многоцелевое назначение.
Проектирование сценария диалогового режима решения задачи состоит в разработке взаимосвязанной последовательности экранных форм и правил перехода между ними.
Содержание экранных форм должно отвечать принципу «дружественности»: обозначения реквизитов должны быть представлены на русском языке в соответствии с привычной для пользователя терминологией, процесс ввода информации должен сопровождаться подсказками и контролем.
Следует обратить особое внимание на контроль правильности вводимой информации, поскольку основная доля ошибок происходит по вине пользователя, а не машины.
Универсальным методом контроля является визуальный контроль. Контроль количественных реквизитов может состоять в проверке на соответствие области допустимых значений. Контроль реквизитов можно осуществлять путем проверки на соответствие разрешенным значениям (см. рисунок 3).
Повышение достоверности при вводе реквизитов-признаков может быть достигнуто за счет того, что они не вводятся с клавиатуры, а выбираются из предложенного на экране списка (см. рисунок 4).
Используются также методы контрольных сумм, верификации, формальный и логический контроль.
Рис. 3. Методы контроля реквизитов в СУБД Microsoft Access
 |
Рис. 4. Использования выбора реквизита-признака
из списка в СУБД Microsoft Access
Результатом проектирования содержания экранной формы является ее реквизитный состав с указанием метода контроля (см. таблицу 5).
Таблица 5.
Реквизитный состав экранной формы
| Наименование реквизита | Имя поля в таблице | Тип данных | Размер поля | Метод контроля | Описание реквизита |
Проектирование отчетов
Отчет представляет собой наилучшее средство для представления информации из базы данных в виде печатного документа. По сравнению с другими средствами вывода информации на печать отчеты обладают двумя принципиальными преимуществами:
· они предоставляют широкие возможности для группирования и вычисления промежуточных и общих итогов для больших наборов данных;
· отчеты могут быть использованы для получения красиво оформленных счетов, заказов, материалов для презентаций и других документов.
Результаты проектирования отчета представляются в виде таблицы 6.
Таблица 6.
Реквизитный состав формы отчета
| Наименование реквизита | Источник данных | Имя поля в таблице | Формула для вычисления |
Результаты проектирования пользовательского интерфейса на примере АРМ кладовщика склада материалов представлены на рисунке 5 и в таблицах 7–11.
Рис. 5. Иерархическое меню АРМ кладовщика склада материалов
Таблица 7.
Реквизитный состав формы «Справочник "Материалы"»
| Наименование реквизита | Имя поля в таблице | Тип данных | Размер поля | Метод контроля | Описание реквизита |
| Наименование материала | Материал | Текстовый | 50 | Визуальный контроль | Уникальное наименование материала |
| Единица измерения | Измерение | Текстовый | 10 | Подстановка значений из списка | Единица измерения размерности материала |
| Цена | Цена | Денежный | Условие на значение (от 0 до 15000) | Цена за единицу | |
| Количество на складе | Остаток | Числовой | Целое | Заполняется автоматически при проведении прихода | Остаток материала на складе |
Таблица 8.
Реквизитный состав формы «Приход»
| Наименование реквизита | Имя поля в таблице | Тип данных | Размер поля | Метод контроля | Описание реквизита |
| Наименование материала | Материал | Текстовый | 50 | Заполняется автоматически при выборе из формы «Справочник "Материалы"» | Уникальное наименование материала |
| Количество | Количество | Числовой | Целое | Заполняется автоматически из формы «Ввод количества» | Количество приходуемого материала |
Таблица 9.
Реквизитный состав формы «Ввод количества»
| Наименование реквизита | Имя поля в таблице | Тип данных | Размер поля | Метод контроля | Описание реквизита |
| Количество материала | Количество | Числовой | Целое | Ограничение размера поля; условие на значение (от 0 до 1500); | Количество приходуемого материала |
Таблица 10.
Реквизитный состав отчета «Приходный ордер»
| Наименование реквизита | Источник данных | Имя поля в таблице | Формула для вычисления |
| Наименование материала | Таблица «Материалы» | Материал | ‑ |
| Цена | Таблица «Материалы» | Цена | ‑ |
| Количество | Форма «Приход» | Количество | ‑ |
| Единицы измерения | Таблица «Материалы» | Измерение | ‑ |
| Сумма | Вычисляемое значение | Сумма | Цена*Кол-во |
| Итого | Вычисляемое значение | – | ∑ Сумма |
| в том числе НДС | Вычисляемое значение | – | Итого/6 |
Таблица 11.
Реквизитный состав отчета «Отчет о наличии материала на складе»
| Наименование реквизита | Источник данных | Имя поля в таблице | Формула для вычисления |
| Наименование материала | Таблица «Материалы» | Материал | ‑ |
| Единицы измерения | Таблица «Материалы» | Измерение | ‑ |
| Цена | Таблица «Материалы» | Цена | ‑ |
| Количество | Таблица «Материалы» | Остаток | ‑ |
| Стоимость | Вычисляемое значение | ‑ | Цена*Остаток |
Тема 10. Принципы и особенности проектирования интегрированных информационных систем.
Интеграция функциональной части системы. Примеры сквозных бизнес-процессов. Организация информационной поддержки цепочек поставок и взаимоотношений с клиентами. Интеграция программного, информационного, организационного и технического обеспечения. Эмерджентность и синергетический эффект.
Тема 11.Анализ требований к корпоративным информационным системам.
Основные требования к корпоративным информационным системам:
· Функциональная полнота системы (выполнение международных стандартов управленческого учета – MRP II, ERP, CSRP; формирование отчетов и ведение учета одновременно по российским и международным стандартам (IAS, GAAP); организационная и функциональная наполненность решаемых системой задач и т.п.) по направлениям (финансы; маркетинг; управление производством и логистика; снабжение; кадры; документооборот; бухгалтерский учет).
· Локализация информационной системы (функциональная (учет особенностей российского законодательства и системы расчетов); лингвистическая (интерфейс, система помощи и документация на русском языке).
· Надежность информационной системы.
· Информационная безопасность (обеспечение парольной системы разграничений доступа к функциям системы; обеспечение многоуровневой системы защиты данных, включающей средства автоматизации вводимой и корректируемой информации, регистрация времени ввода и модификации данных, ведение протокола удалений; наличие программно-аппаратных средств шифровки данных, сертифицированных ФАПСИ).
· Реализация удаленного доступа и работы в распределенных сетях.
· Наличие инструментальных средств адаптации и сопровождения системы (изменение структуры и функций бизнес-процессов; изменение информационного пространства (изменение структуры, добавление и удаление базы данных, модификация полей таблиц, связей, индексов и т.п.); изменение интерфейсов ввода, просмотра и корректировки информации; изменение организационного и функционального наполнения рабочего места пользователя; генератор произвольных отчетов; генератор сложных хозяйственных операций; генератор форм (в т.ч. стандартизированных).
· Масштабируемость.
· Переносимость (возможность миграции) системы на новую программно-техническую платформу.
· Возможность консолидации информации (на уровне предприятий – для объединения информации филиалов, дочерних компаний, предприятий, входящих в холдинг, и т.п.; на уровне отдельных задач; на уровне временных периодов – для выполнения анализа изменений тех или иных показателей за период, превышающий отчетный).
· Наличие специальных средств анализа состояния системы в процессе эксплуатации (анализ архитектуры баз данных; анализ алгоритмов; анализ статистики количества обработанной информации (количество записей, документов, проводок; объем дисковой памяти); журнал выполненных операций; список работающих станций, внутрисистемная почта).
Тема 12. Декомпозиция ИС на подсистемы. Анализ рынка программных средств при подсистемном проектировании.
Декомпозиции информационной системы по сферам управления, производственным ресурсам, бизнес-процессам.
Анализ рынка программных средств при подсистемном проектировании: анализ автоматизированных бухгалтерских систем, управления персоналом, складского учета, оценки финансового состояния предприятия.
Тема 13. Системное проектирование. Анализ типовой ИС для управления производством.
Классификация ИС по размеру предприятия. Примеры типовых информационных систем для крупных, средних и малых промышленных предприятий. Анализ функциональной части ИС промышленного предприятия. Анализ обеспечивающих подсистем ИС. Примеры типовых информационных систем: 1С:Предприятие 8., AXAPTA, SAP R/3.
Тема 14. Проектирование информационной системы с использованием CASE-технологии.
В основе методологии структурного моделирования потоков данных, поддерживаемой программным средством Design/IDEF (IDEF – Integrated Computer-Aided Manufacturing (ICAM) DEFinition), лежит иерархия диаграмм потоков данных (DFD), описывающая процессы преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхнего уровня иерархии (контекстные диаграммы) отражают укрупненные процессы (или подсистемы) информационной системы и их связи с источниками и потребителями информации.
Контекстные диаграммы детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция процессов продолжается до тех пор, пока процессы нижнего уровня не становится просто описать (специфицировать) на алгоритмическом языке с целью дальнейшей автоматической кодогенерации.
Основными компонентами диаграмм потоков данных являются:
· внешние сущности;
· системы/подсистемы;
· процессы;
· накопители данных;
· потоки данных.
Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson) (см. таблицу 12).
Внешняя сущность представляет собой материальный предмет или физическое лицо и является источником или приемником информации. В качестве внешней сущности на DFD диаграмме могут выступать заказчики, поставщики, клиенты, склад, банк и другие. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. При необходимости в процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Таблица 12.
Основные символы диаграмм потоков данных
| Символы DFD | Нотация Гейна-Сарсона | Нотация Йордана |
| Поток данных | 
| |
| Процесс обработки | ||
| Накопитель данных | ||
| Внешняя сущность |
Функциональная модель сложной ИС может быть представлена в общем виде на контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем.
 |
Изображение подсистемы (или системы) на контекстной диаграмме представлено на рисунке 6.
Рис. 6. Подсистема
Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами. Например, может выполняться некоторым подразделением организации, выполняющим обработку входных документов и выпуск отчетов, отдельным сотрудником, программой, установленной на компьютере, специальным логическим устройством и тому подобное.
Изображение процесса на диаграмме потоков данных показано в таблице 12 и на рисунке 7.
Рис. 7. Процесс
Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с глаголом в неопределенной форме (например, вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют пояснительные существительные в винительном падеже. Примеры:
· «Ввести сведения о клиентах»;
· «Выдать информацию о текущих расходах»;
· «Проверить кредитоспособность клиента».
Использование таких глаголов, как «обработать», «модернизировать» или «отредактировать» означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.
Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.
Накопитель (хранилище) данных представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных физически может быть реализован в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д.
 |
Изображение накопителя данных на диаграмме потоков данных показано в таблице 12 и на рисунке 8.
Рис. 8. Накопитель данных
Накопитель данных идентифицируется буквой «D» и произвольным числом. Внутри символа указывается его уникальное в рамках данной модели имя, наиболее точно, с точки зрения аналитика, отражающее информационную сущность содержимого, например, «Поставщики», «Заказчики», «Счета-фактуры», «Накладные». Символы накопителей данных в качестве дополнительных элементов идентификации могут содержать порядковые номера.
Накопитель данных в общем случае является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью.
Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д. Изображение потока данных на диаграмме потоков данных показано в таблице 12 и на рисунке 9. Стрелкой показывается направление потока. Каждый поток данных имеет имя, отражающее его содержание.
 |
Рис. 9. Поток данных
Все потоки данных должны начинаться или заканчиваться процессом. Данные не могут проходить непосредственно от источника до потребителя или между источником/потребителем и хранилищем данных, если они не проходят через промежуточный процесс.
Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС.
После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами).
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация, где показываются основные внутренние процессы подсистемы и соответствующие им внешние сущности, накопители и потоки данных.
При построении иерархически взаимосвязанных DFD должны выполняться следующие правила:
· правило балансировки – означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме;
· правило нумерации – означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.
Конечной вершиной иерархии DFD является миниспецификация. Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.
Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:
· наличия у процесса относительно небольшого количества входных и выходных потоков данных (2–3 потока);
· возможности описания преобразования данных процессом в виде последовательного алгоритма;
· выполнения процессом единственной логической функции преобразования входной информации в выходную;
· возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20–30 строк).
При построении иерархии ДПД переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.
После построения законченной функциональной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.
Построение контекстной DFD АРМ кладовщика склада материалов и ее детализации.
На диаграмме должны быть отражены поставщики и получатели материалов, кладовщик, отдел материально-технического снабжения и бухгалтерия, с которыми связан склад материалов. АРМ должен осуществлять следующие функции: ведение карточек складского учета в электронном виде, регистрация приходных и расходных документов, формирование справок о наличии материалов на складе и их движении.
Образец построения контекстной диаграммы потоков данных АРМ кладовщика склада материалов представлен на рисунке 10. Далее она раскрывается и ее детализация представлена на рисунке 11.
Тема 15. Классификация, примеры CASE-средств и их характеристика.
CASE-средства можно сгруппировать по аналогии с классификацией ИС, для создания которых предназначены данные программные продукты. С этой точки зрения выделяют:
· локальные CASE-средства, служащие для анализа информационной системы и разработки автоматизированных рабочих мест (иногда такой подход называют «кусочной» автоматизацией), поддерживающие один-два типа моделей и методов. Примерами таких CASE-средств являются: Design/IDEF, CASE.Аналитик;
· малые интегрированные CASE-средства, используемые для создания небольших интегрированных ИС и поддерживающие несколько типов моделей и методов. В эту категорию попадают: AllFusion Erwin Data Modeler (прежнее название Erwin), AllFusion Model Manager (прежнее название Bpwin), Silverrun;
· средние интегрированные CASE-средства, поддерживающие от 4 до 10–15 типов моделей и методов. К данному типу следует отнести: Rational Rose, Designer/2000;
· крупные интегрированные CASE-средства, поддерживающие более 15 типов моделей и методов. В эту разновидность входит семейство программных продуктов ARIS.
Контрольная работа. Проводится по материалам тем 14‑15.
Данная контрольная работа предусматривает построение иерархии DFD сотрудника кредитного отдела банка по заданному описанию предметной области.
Описание предметной области
Клиент приходит в банк для оформления кредита. Для этого он отдает сотруднику банка заявление о выдаче кредита и пакет сопроводительных документов (копию паспорта, справку о размере заработной платы и т.д.). В случае возникновения каких-либо вопросов (например, состав документов не соответствует установленным нормам) сотрудник банка направляет запрос клиенту или встречается с ним лично.
Далее банк рассматривает вопрос о выдаче кредита. Сначала проверяется наличие личности заемщика в так называемом «черном списке». В случае положительного ответа следует отказ в выдаче кредита. В случае отрицательного ответа сотрудник банка проверяет предоставленные документы. В случае несоответствия документов действительности или некредитоспособности клиента следует отказ в выдаче кредита и информация о заемщике заносится в «черный список».
Рис 10. Контекстная диаграмма потоков данных АРМ кладовщика склада материалов
Рис. 10. Декомпозиция контекстной диаграммы потоков данных АРМ кладовщика склада материалов
В случае если банк соглашается выдать кредит, следующим шагом является заключение договора между банком и заемщиком. Параллельно с заключением договора формируется график погашения задолженности. При этом момент происходит формирование следующих документов: кредитного договора и графика погашения задолженности. Кроме того, на данном этапе заемщику предоставляют право разделить ответственность с поручителем. В этом случае оформляется договор поручительства и информация о поручителе вносится в систему.
После заключения договора на имя заемщика открывается ссудный счет, с которого осуществляется выдача наличных средств. При выдаче кредита банком формируется расходный кассовый ордер. Заемщик забирает кредит наличными, либо, если существует предварительная договоренность между банком и продавцом товара, здесь же – в банке – осуществляется перечисление полной стоимости товара (собственные средства заемщика плюс кредитные средства) на расчетный счет продавца. При этом формируется приходный кассовый ордер, а заемщику-покупателю выдается квитанция о полной оплате стоимости покупки.
Погашение кредита производится заемщиком ежемесячно по графику погашения задолженности. Каждый платеж фиксируется в системе. На данном этапе возможны следующие ситуации.
В случае преждевременного погашения кредита происходит перерасчет сумм выплат (пересмотр графика погашения задолженности).
В случае нарушения сроков и сумм погашения кредита:
· происходит пересмотр графика погашения задолженности;
· к заемщику применяются штрафные санкции;
· в случае наличия у заемщика поручителя, банк обращается к последнему с требованием погашения кредита.
В случае отказа от погашения кредита:
· в случае наличия у заемщика поручителя, банк обращается к последнему с требованием погашения кредита;
· банком изымается предмет залога;
· происходит расторжение кредитного договора с заемщиком;
· заемщик вносится в «черный список».
После погашения заемщиком всей суммы задолженности следует процедура окончательного погашения кредита: расторгается кредитный договор с заемщиком; осуществляется закрытие ссудного счета заемщика, и выдаются соответствующие документы заемщику.
Тема 16. Пути создания информационных систем: преимущества и недостатки.
Покупка типовой информационной системы на рынке программных продуктов или разработка собственными силами. Покупка отечественной или зарубежной информационной системы. Анализ преимуществ и недостатков путей создания информационной системы.
Тема 17. Планирование и контроль процесса проектирования.
Стратегии внедрения информационной системы: стратегия «большого взрыва» и стратегия процедурного внедрения. Методология ускоренного внедрения информационной системы.
Управление процессом проектирования малых и крупных систем. Сетевое планирование и управление в проектировании информационных систем. Критерии и ограничения в моделях оптимизации процесса проектирования.
РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА:
Нормативно-правовые акты:
1. ГОСТ 34.602–89 Техническое задание на создание автоматизированной системы. – М.: Изд-во стандартов, 1994.
2. ГОСТ 34.601–90 Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания. – М.: Изд-во стандартов, 1991.
3. ГОСТ Р ИСО/МЭК 12207–99 Информационная технология. Процессы жизненного цикла программных средств. – М.: Изд-во стандартов, 2003.
Основная:
4. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие. – М.: Финансы и статистика, 2004. – 192 с.
5. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2005. – 544 с.
6. Ильин В.В. Моделирование бизнес-процессов. Практический опыт разработчика. – М.: ООО «И.Д. Вильямс», 2006. – 176 с.
7. Прикладная информатика в экономике: Учеб. пособие / Бугорский В.Н., Емельянов А.А., Порховник Ю.М., Соколов Р.В., Фомин В.И., Чиркова М.Ю / Под ред. д-ра экон. наук, профессора Михайлушкина А.И.. – СПб.: СПбГИЭУ, 2005. – 412 с.
8. Проектирование экономических информационных систем: методология и современные технологии: Учебное пособие / В.П. Романов, Н.З. Емельянова, Т.Л. Партыка. – М.: Издательство «Экзамен», 2005. – 256 с.
9. Проектирование экономических информационных систем: Учебник/ Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. – М.: Финансы и статистика, 2005. – 510 с.
10. Структурные модели бизнеса: DFD-технологии; Под ред. Г.Н. Калянова. – М.: Финансы и статистика, 2003. – 256 с.
11. Черемных С.В., Семенов И.О., Ручкин В.С. Моделирование и анализ систем. IDEF-технологии: практикум. – М.: Финансы и статистика, 2005. – 192 с.
Дополнительная:
1. Волкова В.Н., Кузин Б.И. и др. Информационные системы. – СПб.: Изд-во СПбГТУ, 2004. – 213 с.
2. Диго С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2005. – 592 с.
3. Жарков С. Shareware: профессиональная разработка и продвижение программ. – М.: BHV-СПб, 2002. – 320 с.
4. Избачков Ю.С. Информационные системы: Учебное пособие/ Избачков Ю.С., Петров В.Н. – 2-е изд. – СПб: Питер, 2005. – 655 с.
5. Лодон Дж. Управление информационными системами = Management information systems: Учебник/ Лодон Дж., Лодон К.; Пер. с англ. под ред. Д.Р.Трутнева. – 7-е изд. – СПб: Питер, 2005. – 910 с.
6. Маклаков С.В. Моделирование бизнес-процессов с AllFusion Process Modeler (BPwin 4.1). – М.: Диалог-МИФИ, 2003. – 240 с.
7. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. – М.: Диалог-МИФИ, 2003. – 427 с.
8. Питеркин С.В., Оладов Н.А., Исаев Д.В. Точно вовремя для России. Практика применения ERP-систем. – М.: Альпина Паблишер, 2002. – 368 с.
9. Седельников А. Основные принципы проектирования интерфейсов. Интернет: http://www.nestor.minsk.by/kg.
10. Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии. Практикум. – М.: Горячая линия – Телеком, 2003. – 160 с.
11. Якобсон А. Унифицированный процесс разработки программного обеспечения / Якобсон А., Буч Г., Рамбо Дж.; Пер. с англ. В. Горбунова. – СПб: Питер, 2002. – 492 с.
12. Gordon S. Information Systems: Management Approach/ Gordon S., Gordon J. – 3rd edition: Wiley, 2004. – 429 p.
13. Pearlson K. Managing and Using Information Systems: A Strategic Approach/ Pearlson K., Saunders C. – 2 edition: Wiley, 2004. – 345 p.
14. Ward J. Strategic Planning for Information Systems/ J. Ward, J. Peppard. – 3-d edition. – England: John Wiley & Sons, LTD, 2004. – 624 p.
[1] Данные правила разработаны американским специалиста в области проектирования интерфейсов Якобом Нильсеном (Jakob Nielsen) совместно с Рольфом Моличем (Rolf Molich).
Дата добавления: 2018-02-15; просмотров: 410; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!