Файл: 1 разработка сценария внедрения.pdf

2
СОДЕРЖАНИЕ
1 РАЗРАБОТКА СЦЕНАРИЯ ВНЕДРЕНИЯ
ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ РАБОЧЕГО МЕСТА ... 4 1.1 ЦЕЛЬ РАБОТЫ .................................................................. 4 1.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ................................. 4 1.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ......................... 44 1.4 КОНТРОЛЬНЫЕ ВОПРОСЫ......................................... 44 2 РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ НА
ВНЕДРЕНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ...................... 46 2.1 ЦЕЛЬ РАБОТЫ ................................................................ 46 2.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ............................... 46 2.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ......................... 52 2.4 КОНТРОЛЬНЫЕ ВОПРОСЫ......................................... 52 3 РАЗРАБОТКА ГРАФИКА РАЗРАБОТКИ И ВНЕДРЕНИЯ
ИНФОРМАЦИОННОЙ СИСТЕМЫ ............................................... 54 3.1 ЦЕЛЬ РАБОТЫ ................................................................ 54 3.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ............................... 54 3.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ......................... 77 3.4 КОНТРОЛЬНЫЕ ВОПРОСЫ......................................... 78 4 СРАВНИТЕЛЬНЫЙ АНАЛИЗ МЕТОДОЛОГИЙ
ПРОЕКТИРОВАНИЯ ........................................................................ 79 4.1 ЦЕЛЬ РАБОТЫ ................................................................ 79 4.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ............................... 79 4.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ......................... 83 4.4 КОНТРОЛЬНЫЕ ВОПРОСЫ......................................... 83 5 АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ ПОДРАЗДЕЛЕНИЯ ... 85 5.1 ЦЕЛЬ РАБОТЫ ................................................................ 85 5.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ............................... 85 5.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ......................... 95 5.4 КОНТРОЛЬНЫЕ ВОПРОСЫ......................................... 95 6 РАЗРАБОТКА И ОФОРМЛЕНИЕ ПРЕДЛОЖЕНИЙ ПО
РАСШИРЕНИЮ ФУНКЦИОНАЛЬНОСТИ
ИНФОРМАЦИОННОЙ СИСТЕМЫ ............................................... 97 6.1 ЦЕЛЬ РАБОТЫ ................................................................ 97 6.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ............................... 97

3 6.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ....................... 106 6.4 КОНТРОЛЬНЫЕ ВОПРОСЫ....................................... 106 7 РАЗРАБОТКА ПЕРЕЧНЯ ОБУЧАЮЩЕЙ
ДОКУМЕНТАЦИИ НА ИНФОРМАЦИОННУЮ СИСТЕМУ .. 107 7.1 ЦЕЛЬ РАБОТЫ .............................................................. 107 7.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ............................. 107 7.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ....................... 111 7.4 КОНТРОЛЬНЫЕ ВОПРОСЫ....................................... 111 8 РАЗРАБОТКА РУКОВОДСТВА ОПЕРАТОРА .............. 112 8.1 ЦЕЛЬ РАБОТЫ .............................................................. 112 8.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ............................. 112 8.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ....................... 115 8.4 КОНТРОЛЬНЫЕ ВОПРОСЫ....................................... 115 9 РАЗРАБОТКА МОДЕЛЕЙ ИНТЕРФЕЙСОВ
ПОЛЬЗОВАТЕЛЕЙ ......................................................................... 117 9.1 ЦЕЛЬ РАБОТЫ .............................................................. 117 9.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ............................. 117 9.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ....................... 120 9.4 КОНТРОЛЬНЫЕ ВОПРОСЫ....................................... 120 10 НАСТРОЙКА ДОСТУПА К СЕТЕВЫМ
УСТРОЙСТВАМ ............................................................................. 121 10.1 ЦЕЛЬ РАБОТЫ ............................................................ 121 10.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ........................... 121 10.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ..................... 126 10.4 КОНТРОЛЬНЫЕ ВОПРОСЫ .................................... 127 11 НАСТРОЙКА ПОЛИТИКИ БЕЗОПАСНОСТИ ............ 128 11.1 ЦЕЛЬ РАБОТЫ ............................................................ 128 11.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ........................... 128 11.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ..................... 143 11.4 КОНТРОЛЬНЫЕ ВОПРОСЫ .................................... 143 12 ВЫПОЛНЕНИЕ ЗАДАЧ ТЕСТИРОВАНИЯ В
ПРОЦЕССЕ ВНЕДРЕНИЯ. ............................................................ 144 12.1 ЦЕЛЬ РАБОТЫ ............................................................ 144 12.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ........................... 144 12.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ ..................... 152 12.4 КОНТРОЛЬНЫЕ ВОПРОСЫ .................................... 152

4 1 РАЗРАБОТКА СЦЕНАРИЯ ВНЕДРЕНИЯ
ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ РАБОЧЕГО МЕСТА
1.1 ЦЕЛЬ РАБОТЫ
Цель работы – изучить принципы создания и внедрения ин- формационной системы.
1.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ
1.2.1 Принципы создания информационной системы
Многие пользователи компьютерной техники и программ- ного обеспечения неоднократно сталкивались с ситуацией, когда программное обеспечение, хорошо работающее на одном компь- ютере, не работает на другом таком же устройстве. Или систем- ные блоки одного вычислительного устройства не стыкуются с аппаратной частью другого. Или информационная система дру- гой компании упорно не желает обрабатывать данные, которые вы подготовили в информационной системе у себя на рабочем месте. Эта проблема называется проблемой совместимости вы- числительных, телекоммуникационных и информационных уст- ройств.
Развитие систем и средств вычислительной техники, расши- ренное их внедрение во все сферы науки, техники, сферы обслу- живания и быта привели к необходимости объединения конкрет- ных вычислительных устройств и реализованных на их основе информационных систем в единые информационно- вычислительные системы (ИВС) и среды. При этом разработчики
ИВС столкнулись с рядом проблем.
Например, разнородность технических средств вычисли- тельной техники с точки зрения организации вычислительного процесса, архитектуры, системы команд, разрядности процессора и шины данных и т. д. потребовала создания физических интер- фейсов, реализующих, как правило, взаимную совместимость устройств. При увеличении числа типов интегрируемых уст- ройств сложность организации физического интерфейса между ними существенно возрастала. Разнородность программируемых

5 сред, реализуемых в конкретных вычислительных устройствах и системах, с точки зрения многообразия операционных систем, различия в разрядности и прочих особенностей привела к созда- нию программных интерфейсов между устройствами и система- ми. При этом необходимо отметить, что достигнуть полной со- вместимости программных продуктов, разработанных для кон- кретной программной среды, в другой среде удавалось не всегда.
Разнородность интерфейсов общения в системе «человек- компьютер» требовала постоянного согласования программно- аппаратного обеспечения и переобучения кадров.
1) Принцип «открытости» информационной системы.
Решение проблем совместимости привело к разработке большого числа международных стандартов и соглашений в сфе- ре применения информационных технологий и разработки ин- формационных систем. Основополагающим понятием стало по- нятие открытые системы.
Термин «открытая система» сегодня можно определить как
«исчерпывающий и согласованный набор международных стан- дартов на информационные технологии и профили функциональ- ных стандартов, которые специфицируют интерфейсы, службы и поддерживающие их форматы, чтобы обеспечить взаимодействие и мобильность программных приложений, данных и персонала».
Это определение, сформулированное специалистами инсти- тута IEEE (Institute of Electrical and Electronic Engineers), унифи- цирует содержание среды, которую предоставляет открытая сис- тема для широкого использования. В настоящее время общепри- знанным координационным центром по разработке и согласова- нию стандартов открытых систем является OASIS (Organization for the Advancement of Structured Information Standards).
Общие свойства открытых информационных систем можно сформулировать следующим образом:
– расширяемость/масштабируемость: обеспечение воз- можности добавления новых функций ИС или изменения некото- рых уже имеющихся при неизменных остальных функциональ- ных частях ИС;
– мобильность/переносимость: обеспечение возможности переноса программ, данных при модернизации или замене аппа- ратных платформ ИС и возможности работы с ними специали-

6 стов, пользующихся ИТ, без их переподготовки при изменениях
ИС;
– взаимодействие: способность к взаимодействию с други- ми ИС (технические средства, на которых реализована информа- ционная система, объединяются сетью или сетями различного уровня: от локальной до глобальной);
– стандартизуемость: ИС проектируются и разрабатывают- ся на основе согласованных международных стандартов и пред- ложений, реализация открытости осуществляется на базе функ- циональных стандартов (профилей) в области информационных технологий;
– дружественность к пользователю: развитые унифициро- ванные интерфейсы в процессах взаимодействия в системе «че- ловек-машина», позволяющие работать пользователю, не имею- щему специальной «компьютерной» подготовки.
Новый взгляд на открытые системы определяется тем, что эти черты рассматриваются в совокупности, как взаимосвязан- ные, и реализуются в комплексе, что вполне естественно, по- скольку все указанные выше свойства дополняют друг друга.
Только в совокупности возможности открытых систем позволяют решать проблемы проектирования, разработки и внедрения со- временных информационных систем.
Обобщенная структура любой ИС может быть представлена двумя взаимодействующими частями:
– функциональной части, включающей прикладные про- граммы, которые реализуют функции прикладной области;
– среды или системной части, обеспечивающей исполне- ние прикладных программ.
– С этим разделением тесно связаны две группы вопросов стандартизации:
– стандарты интерфейсов взаимодействия прикладных программ со средой ИС, прикладной программный интерфейс
(Application Program Interface – API);
– стандарты интерфейсов взаимодействия самой ИС с внешней для нее средой (External Environment Interface – EEI).
Эти две группы интерфейсов определяют спецификации внешнего описания среды ИС – архитектуру, с точки зрения ко-

7 нечного пользователя, проектировщика ИС, прикладного про- граммиста, разрабатывающего функциональные части ИС.
Спецификации внешних интерфейсов среды ИС и, как будет видно далее, спецификации интерфейсов взаимодействия между компонентами самой среды, – это точные описания всех необхо- димых функций, служб и форматов определенного интерфейса.
Совокупность таких описаний составляет эталонную модель от- крытых систем (Reference Open System Model).
Эта модель используется более 20 лет и определяется сис- темной сетевой архитектурой (SNA), предложенной IBM в 1974 году. Она основана на разбиении вычислительной среды на семь уровней, взаимодействие между которыми описывается соответ- ствующими стандартами, и обеспечивает связь уровней вне зави- симости от построения уровня в каждой конкретной реализации
(рисунок 1.1). Основным достоинством этой модели является де- тальное описание связей в среде с точки зрения технических уст- ройств и коммуникационных взаимодействий. Вместе с тем она не принимает в расчет взаимосвязь с учетом мобильности при- кладного программного обеспечения.
Рисунок 1.1 – Семиуровневая модель взаимодействия информационных систем

8
Эталонная модель среды открытых систем (OSE/RM) опре- деляет разделение любой информационной системы на приложе- ния (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют. Между приложения- ми и средой определяются стандартизованные интерфейсы (API), которые являются необходимой частью профилей любой откры- той системы. Кроме того, в профилях ИС могут быть определены унифицированные интерфейсы взаимодействия функциональных частей друг с другом и интерфейсы взаимодействия между ком- понентами среды ИС.
Методологически важно наряду с рассмотренными моделя- ми среды ИС предложить модель создания ИС, которая имела бы те же аспекты функциональных групп компонентов (пользовате- ли, функции, данные, коммуникации). Такой подход обеспечит сквозной процесс проектирования и сопровождения на всех ста- диях эксплуатации ИС и возможность обоснованного выбора стандартов на разработку систем и документирование проектов.
Компания является сложной онтологической (понятийной) структурой, состоящий из определенной совокупности сущно- стей и взаимосвязей (рисунок 1.2).
Рисунок 1.2 – Онтологическое поле современной компании

9
Взаимодействия между еѐ элементами, определяемые биз- нес-логикой и закрепленные в наборе бизнес-правил, и является деятельностью компании. Информационная система «отражает» логику и правила, организуя и преобразуя информационные по- токи, автоматизирует процессы работы с данными и информаци- ей и визуализирует результаты в виде наборов отчетных форм.
Поэтому для начала следует создать бизнес-модель предприятия, которая является отображением предприятия и его информаци- онно-управляющей системы.
При создании модели формируется «язык общения» руково- дителей предприятия, консультантов, разработчиков и будущих пользователей, позволяющий выработать единое представление о том, ЧТО и КАК должна делать система управления предприяти- ем (корпоративная система управления). Такая бизнес-модель – осязаемый результат, с помощью которого можно максимально конкретизировать цели внедрения ИС и определиться со сле- дующими параметрами проекта:
– основные цели бизнеса, которые можно достичь посред- ством автоматизации процессов;
– перечень участков и последовательность внедрения мо- дулей ИС;
– фактическая потребность в объемах закупаемого про- граммного и аппаратного обеспечения;
– реальные оценки сроков развертывания и запуска ИСУ;
– ключевых пользователей ИС и уточненный список чле- нов команды внедрения;
– степень соответствия выбранного вами прикладного про- граммного обеспечения специфике бизнеса вашей компании.
В основе модели всегда лежат бизнес-цели предприятия, полностью определяющие состав всех базовых компонентов мо- дели:
– бизнес-функции, описывающие, ЧТО делает бизнес;
– основные, вспомогательные и управленческие процессы, описывающие, КАК предприятие выполняет свои бизнес- функции;
– организационно-функциональную структуру, опреде- ляющую, ГДЕ исполняются бизнес-функции и бизнес-процессы;

10
– фазы, определяющие, КОГДА (в какой последовательно- сти) должны быть внедрены те или иные бизнес-функции;
– роли, определяющие, КТО исполняет бизнес-функции и
КТО является «хозяином» бизнес-процессов;
– правила, определяющие связь и взаимодействие между всеми ЧТО, КАК, ГДЕ, КОГДА и КТО.
После построения бизнес-модели (или параллельно с этим) можно приступать к формированию модели проектирования, реализации и внедрения самой ИС (рисунок 1.3).
Рисунок 1.3 – Модели проектирования, реализации и внедрения
Опыт создания и использования «заказных» ИС позволяет условно выделить следующие основные этапы их жизненного цикла:
– определение требований к системе и их анализ – опреде- ление того, что должна делать система;
– проектирование – определение того, как система будет делать то, что она должна делать; проектирование это, прежде всего, спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе;
– разработка – создание функциональных компонентов и отдельных подсистем, соединение подсистем в единое целое;
– тестирование – проверка функционального соответствия системы показателям, определенным на этапе анализа;
– внедрение – установка и ввод системы в действие;
– функционирование – штатный процесс эксплуатации в соответствии с основными целями и задачами ИС;
– сопровождение – обеспечение штатного процесса экс- плуатации системы на предприятии заказчика.
Определение требований к системе и анализ является пер- вым этапом создания ИС, на котором требования заказчика уточ-

11 няются, согласуются, формализуются и документируются. Фак- тически на этом этапе дается ответ на вопрос: «Для чего предна- значена и что должна делать информационная система?». Именно здесь лежит ключ к успеху всего проекта.
Целью системного анализа является преобразование общих, расплывчатых знаний об исходной предметной области (требова- ний заказчика) в точные определения и спецификации для разра- ботчиков, а также генерация функционального описания систе- мы. На этом этапе определяются и специфицируются:
– внешние и внутренние условия работы системы;
– функциональная структура системы;
– распределение функций между человеком и системой, интерфейсы;
– требования к техническим, информационным и про- граммным компонентам системы,
– требования к качеству и безопасности;
– состав технической и пользовательской документации;
– условия внедрения и эксплуатации.
Разработка перечисленных выше спецификаций при созда- нии ИС, предназначенной для автоматизации управленческих процессов, в общем случае проходит четыре стадии.
Первая стадия анализа – структурный анализ предприятия – начинается с исследования того, как организована система управления предприятием, с обследования функциональной и информационной структуры системы управления, определения существующих и возможных потребителей информации.
По результатам обследования аналитик на первой стадии строит обобщенную логическую модель исходной предметной области, отображающую ее функциональную структуру, особен- ности основной деятельности и информационное пространство, в котором эта деятельность осуществляется (рисунок 1.4). На этом материале аналитик строит функциональную модель «Как есть»
(As Is).