2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл информационных систем в стандартах представляет собой набор этапов, частных работ и операций в последовательности их выполнения и взаимосвязях, регламентирующих ведение работ от подготовки технического задания до завершения испытаний ряда версий и окончания эксплуатации ИС. Стандарты включают правила описания исходной информации, способов и методов выполнения операций, устанавливают контроль технологических процессов, требования к оформлению их результатов. А также регламентируют содержание технологических и эксплуатационных документов на комплексы программ. Они определяют организационную структуру коллектива, обеспечивают распределение и планирование заданий, а также контроль над этапами создания комплекса ИС. [9] Основными стандартами, описывающие жизненный цикл информационной системы, являются:
• ГОСТ 34.601-90 — стандарт распространяется на автоматизированные системы, используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях. Стандарт устанавливает стадии и этапы создания автоматизированной системы.
• ISO 12207 — стандарт применяется при приобретении систем, программных продуктов и оказании соответствующих услуг (внедрение, сопровождение); а также при поставке, разработке, эксплуатации и сопровождении программных продуктов и программных компонентов программно-аппаратных средств как в самой организации, так и вне ее.
• ISO 15288 — стандарт обеспечивает общие основы процессов, составляющих жизненной цикл систем, созданных человеком. Этот жизненный цикл охватывает концепции идей вплоть до снятия системы с эксплуатации. Он обеспечивает процессы для приобретения и поставки системы.
• RUP (Rational Unified Process – рациональный унифицированный процесс) — это методология разработки ПО, созданная и распространяемая корпорацией Rational Software. Она описывает упорядоченный подход к распределению задач и обязанностей в организации-разработчике.
• XP (eXtreme Programming) — методология содержит совершенно иные базовые принципы, нежели RUP. Основными чертами являются определение точных кратковременных планов (как правило, недельных), постоянное перепланирование, тесное общение с заказчиком. Эта методология больше подходит для полу-исследовательских и инновационных проектов.
• MSF (Microsoft Solutions Framework — методология создания программных решений) — В модели процессов приводится общее описание организации работ над проектом по разработке и внедрению ИТ-решений. Предлагаемая схема достаточно гибка и может применяться к самым разным проектам в области информационных технологий. В версии 3 концепция была расширена и теперь охватывает практически весь цикл создания решений — начиная с их обсуждения и заканчивая внедрением.
• COBIT (Control Objectives for Information and Related Technology – цели контроля для информационных и смежных технологий) — основная идея стандарта COBIT выражается следующим образом: все ресурсы информационной системы должны управляться набором естественно сгруппированных процессов для обеспечения компании необходимой и надежной информацией.
• Oracle CDM (Custom Development Method – методика разработки ИС под заказ) — позволяет стандартизировать процесс создания приложений. CDM охватывает полный жизненный цикл разработки приложений, описывая последовательность и взаимную зависимость задач, решаемых в процессе разработки.
Для описания жизненных циклов ИС был выбран стандарт ГОСТ 34.601-90, как стандарт, охватывающий большинство автоматизированных систем. Международный стандарт ГОСТ 34.601-90 определяет стратегию и общий порядок в создании и эксплуатации ПО и охватывает весь жизненный цикл ПО от формирования идей до завершения всего ЖЦ [13].
Выбранный способ автоматизации построен согласно стандарту ГОСТ 34.601-90 так же учитывались ГОСТ 34.201-89 (Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем), ГОСТ 34.602-89 (Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы), согласно требованиям РД 50-34.698-90 (методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов) и включает в себя следующие стадии и этапы создания автоматизированной системы [1]:
1. Формирование требований к ИС (выполняется аналитиками компании).
1. Изучение предметной области и обоснование необходимости автоматизации;
2. Составление требований к ИС. Требования должны охватить все аспекты работы ИС и наиболее полно ображать их состав;
3. Составление отчета о изучении предметной области и требований к ИС.
На этом этапе составляются и заполняются опросники, анкеты, отчёты об обследовании, коммерческое предложение, план-график работ и т.д.
2. Разработка концепции ИС (выполняется рабочей группой)
1. Разработка концепции ИС удовлетворяющей требованиям, сформированным на первом этапе.
На этом этапе предоставляются отчёты по результатам обследования и предложения по модернизации программно-технического комплекса компании.
3. Формирование технического задания (выполняется аналитиками компании).
1. Разработка и утверждение технического задания для ИС.
На данном этапе создается четко сформулированное задание для ИС включающее в себя требования к системе, перечень требуемых работ и план проведения работ.
4. Технический проект (выполняется разработчиками).
1. Разработка решения по системе. Создание программно аппаратного решения. Тестовое эксплуатирование.
5. Рабочая документация (выполняется разработчиками системы).
1. Разработка сопроводительной документации или пояснительной записки к проекту.
На данном этапе создаются следующие документы: протокол проведения тестовых испытаний и пояснительная записка по разработке ИС.
6. Ввод в эксплуатацию (выполняется разработчиками системы).
1. Проведение предварительных этапов (если требуется) по модернизации аппартно-программного обеспечения компании;
2. Пусконаладочные работы;
3. Проведение предварительных испытаний (не фиксируются, требуются только для проверки основных компоненто ви более тонкой настройки системы);
4. Запуск тестовых испытаний (протоколируются, являются основанием сдачи системы в эксплуатацию).
7. Дальнейшее сопровождение информационной системы (выполняется разработчиками системы или обученными специалистами).
1. Обслуживание системы во время промышленного эксплатирования. Решение всех возникающих вопросов.
Жизненный цикл информационной системы состоит из основных, вспомогательных и организационных пунктов. Рассмотрим их поподробнее:
• Основные:
o Разработка (Подготовка платформы. Написание ИС. Подготовка документации.);
o Эксплуатация системы;
o Сопровождение (Поддержка пользователей. Исправление ошибок в системе.).
• Вспомогательные
o Управление настройками системы (администрирование системы на протяжении ЖЦ ИС);
o Проверка состояния системы;
o Разрешение проблем (решение проблем, возникающих во время разработки и эксплуатации системы).
• Организационные
o Подготовка аппаратного-программного обеспечения к ИС (инсталляция и настройка необходимых аппаратных комплексов и ПО для работы с ИС);
o Усовершенствование (Обновление и исправления ИС);
o Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала).
В процессе внедрения ИС обычно используют тактику параллейного функционирования со старым образом работы, что позволит провести ингеграцию более мягко и предостеречь компанию от потери важных данных в случае своев на этапе отладки программы.
Описанный в концепции функционал системы будет реализован по этапам, описанным в таблице 2.1.
Таблица 2.1
Этапы разработки ИС
| Этап | Содержание | Срок |
| 1. Разработка ТЗ | Разработка и утверждение требований к ИС, разработка модели системы «как должно быть»; согласование технического задания на ИС; | 45 дней |
| 2. Разработка системы | Создание ИС основываясь на требованиях ТЗ, разработка документации; развертывание и настройка ИС; обучение персонала компании. | 39 дней |
| 3. Опытная эксплуатация | Проведение тестовой эксплуатации ИС; доработка системы. Сдача ИС в промышленную эксплуатацию. | 45 дней |
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Любой проект по созданию информационной системы предприятия всегда включает множество задач, связанных с общим управлением проектом, разработкой ПО, проектированием ИС, внедрением, каждая из которых сама по себе является проектом с присущими ему особенностями. Поэтому в ходе разработки существуют различные риски.
Риски сопровождают весь жизненный цикл ИС. Возможными влияниями на данную ИС являются: увеличение длительности проекта, увеличение стоимости проекта и т.д. [12] Рассмотрим риски более подробно:
• Существует риск не корректно или не точно описать требования к ИС. Это может повлечь затраты на переработку ТЗ или самой ИС. Этого можно избежать, если перепроверить ТЗ или дать на проверку лицу не учавствующему непосредственно в разработке.
• На стадии эксплуатации может произойти изменения в квалификации сотрудников использующих ИС а так же риски неполноты проверки функциональных возможностей и пропуск ошибки. Это может привести к непредвидимым последствиям, таким как, вывод из строя ИС, оборудования и т.д. Этот риск можно избежать контролируя уровень знаний сотрудников приступающих к взаимодействию с ИС.
• Во время разработки ИС может возникнуть риск с неописанными свойствами программы или языка программирования. В свою очередь это приведёт к временным затратам. Этот риск избежать нельзя.
Таблица 2.2
Перечень возможных рисков
2.1.3 Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе включает в себя следующие аспекты:
• защита информации непосредственно в информационной системе от внутренних угроз;
• защита информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика разделения прав доступа. Характеристика политики приведена в таблице 2.3.
Таблица 2.3
Разграничение прав пользователей
Защита от внешних угроз осуществляется путем применения следующих способов:
— использованием программно-аппаратных комплексов;
— разработкой и соблюдение политик безопасности;
— использованием защищенных каналов связи при передаче информации;
— использованием антивирусных средств;
— физической защитой помещений с наиболее ценной информацией.
Характеристика используемых средств от внешних угроз информационной безопасности приведена в таблице 2.4.
Таблица 2.4
Характеристика используемых средств от внешних угроз информационной безопасности
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Информационная модель представляет собой схему движения входных, промежуточных и результативных потоков и функций предметной области. Кроме того, она объясняет, на основе каких входных документов и какой нормативно-справочной информации происходит выполнение функций по обработке данных и формирование конкретных выходных документов. Информационная модель представлена на рис. 2.1.
Рисунок 2.1 Информационная модель системы
В соответствии с приведенной информационной моделью, работа системы осуществляется следующим образом.
Администратор системы регистрирует менеджеров, тем самым формируя содержание справочника «Менеджеры». Среди прочих атрибутов администратор указывает пароль и логин для входа в систему.
Далее администратор заполняет все справочники, а также в случае необходимости редактирует их
Менеджер регистрирует заявку, после чего формируются выходные документы, такие, как Акт приема и Журнал приема.
2.2.2 Характеристика нормативно-справочной, входной и оперативной информации
В разработанной системе в качестве основного используется такой входной документ, как гарантийный талон. Именно на его основе ведется учет оборудования. Выглядеть данный документ может по разному, в зависимости от типа оборудования и производителя. Макет данного документа в его общей форме приведен в Приложении 1, рисунок П 1.1.
В качестве входной в системе используется информация, которая импортируется из следующих документов, указанных в таблице 2.5. Там же приведен перечень первичных показателей, источник документа, а также ссылка на приложение, в котором приведена форма для ввода документа в систему.
Таблица 2.5
Описание входных документов
В системе используются справочники, приведенные в таблице 2.5.
Таблица 2.6
Перечень используемых справочников
Перечень реквизитов, используемых в указанных справочниках, приведен в таблице 2.7.
Таблица 2.7
Реквизитный состав справочников
2.2.3 Характеристика результатной информации
В качестве основных выходных документов в системе формируются акт приема оборудования, а также журнал приема оборудования.
Макеты данных документов приведены в Приложении 2, рисунок П 2.1 и П 2.2.
Описание результатных документов приведено в таблице 2.8.
Таблица 2.8
Описание выходных документов
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
Основным действующим лицом в разработанной системе является менеджер, который производит регистрацию заявки на ремонт, а также формирование результатных документов – акта приема и журнала приема. Дерево функций для менеджера представлено на рисунке 2.2.
Рисунок 2.2 Дерево функций системы для менеджера
Администратор системы обладает более расширенными возможностями. Он производит первичное наполнение справочников, а также обеспечивает их дальнейшее ведение, Кроме того, он также имеет возможность просмотра результатных документов. Дерево функций для администратора представлено на рисунке 2.3.
Рисунок 2.3 Дерево функций системы для менеджера
Сценарии диалога, формирующиеся на основе деревьев функций, приведены на рисунках 2.4 и 2.5.
Рисунок 2.4 Сценарий диалога для менеджера
Рисунок 2.5 Сценарий диалога для администратора
2.3.2 Характеристика базы данных
В разработанном приложении используется СУБД MySQL. ER-диаграмма используемой базы данных приведена на рисунке 2.6.
Рисунок 2.6 ER-диаграмма базы данных
Назначение таблиц представлено в таблице 2.9.
Таблица 2.9
Назначение таблиц базы данных
Реквизитный состав таблиц, описание типа и назначения полей приведены в таблицах 2.10-2.17.
Таблица 2.10
Структура таблицы «Klient»
Таблица 2.11
Структура таблицы «Dolg»
Таблица 2.12
Структура таблицы «Sotr»
Таблица 2.13
Структура таблицы «Garant»
Таблица 2.14
Структура таблицы «Obor»
Таблица 2.13
Структура таблицы «Garant»
Таблица 2.14
Структура таблицы «Obor»
Таблица 2.16
Структура таблицы «Vender»
Таблица 2.17
Структура таблицы «Zav»
2.3.3 Структурная схема пакета (дерево вызова программных модулей)
Характеристика программных модулей представлена в таблице 2.18.
Таблица 2.18
Характеристика программных модулей
2.3.4 Описание программных модулей
В качестве расчетного модуля на рисунке 2.7. приведен алгоритм добавления данных в справочники.
Рисунок 2.7 Алгоритм работы со справочниками
2.4 Контрольный пример реализации проекта и его описание
Работа в системе начинается с заполнения справочников. На рисунке 2.8 приведена форма заполнения справочника «Производители», а также список производителей.
Рисунок 2.8 Справочник «Производители»
Форма для заполнения справочника «Типы гарантий» и содержание данного справочника приведено на рисунке 2.9.
Рисунок 2.9 Справочник «Типы гарантий»
Остальные справочники организованы аналогично.
При заполнении каждого из справочников необходимо заполнить необходимые поля, после чего нажать кнопку «Зарегистрировать».
При вводе осуществляется проверка данных на корректность, а также проверяется заполнение обязательных полей. Рассмотрим эту функцию на примере справочника «Менеджеры».
Рисунок 2.10 Проверка данных на обязательность и корректность
При попытке ввода букв латинского алфавита в поле «Фамилия» система показывает сообщение – «только русские буквы», аналогично при незаполнении обязательных полей (например, «Логин» и «Пароль»), показывается сообщение – «Поле обязательно к заполнению».
На рисунках 2.11 и 2.12 приведены экранные формы списка клиентов физических и юридических лиц.
Рисунок 2.11 Редактирование списка клиентов-физических лиц
Рисунок 2.12 Редактирование списка клиентов — юридических лиц
При нажатии иконки с изображением ножниц происходит переход на страницу редактирования данных клиента, с изображением креста – удаление клиента из списка.
Менеджер после прохождения авторизации имеет возможность регистрации заявки:
Рисунок 2.13 Форма регистрации заявки на гарантийное обслуживание
После регистрации заявки появляется ссылка на сформированный акт приема.
Рисунок 2.14 Ссылка на акт приема
Образец акта приведен в Приложении 2, на рисунке П 2.2.
Менеджер также имеет возможность просмотра списка заявок:
Рисунок 2.15 Список заявок
При этом при нажатии на иконку с изображением буквы I можно просмотреть подробности заявки:
Рисунок 2.16 Всплывающее окно с подробностями заявки
Листинг основных программных модулей приведен в Приложении 3.