51
использоваться. Для систем масштаба крупной организации имеется продукт
Oracle Database Enterprise Edition корпоративной версии, включающий целый
набор опций, архитектурно и функционально расширяющих функции сервера.
Именно Oracle Database Enterprise Edition работает на кластерах (с опцией Parallel
Server, по версию 8i включительно или RAC - Real Application Cluster, начиная с
версии 9i и старше), помогая реализовывать системы высокой готовности.
Продукт Oracle Database Standard Edition в стандартной редакции рассчитан на
организации среднего масштаба или подсистемы одной крупной компании. Для
использования персонально есть Oracle Database Personal Edition в персональной
версии.
Огромным преимуществом Oracle перед конкурентами (особенно перед
DB2) является высокая схожесть кода разных версий сервера БД Oracle для всех
платформ, что позволяет гарантировать стабильность и предсказуемость работы
Oracle на всех ПК, входящих в состав сети. Все варианты сервера Oracle в своей
основе содержат идентичный исходный программный код и сходи
функционально, исключение составляют некоторые опции, добавляемые к Oracle
Database Enterprise Edition и отсутствующие в Oracle Database Standard Edition.
Поэтому для всех платформ существует единая СУБД в различных версиях
с одинаковым поведением и одинаковой функциональностью вне зависимости от
платформы, на которой на работает.
Жесткая технологическая схема разработки Oracle, основанная на
принципах идентичности исходного программного кода для разных версий и
платформ, отлична от схем других компаний. Например, СУБД DB/2 является
семейством продуктов, но никак не единым продуктом. Функционально версия
DB2 для IBM S/390 очень отличается от DB2 для платформ UNIX и NT, что
позволяет считать их вообще совершенно разными продуктами.
СУБД Oracle опускает детали реализации механизмов управления данным
на отдельной платформе, что позволяет судить о практически полном
единообразии созданных на одной платформе, на другие платформы без каких-то
значимых изменений как в структурах БД, так и коде предложения. При этом
базовым критерием, определяющим доступность переноса тех или иных
52
компонентов системы между платформами, становится полное отсутствие в них
машинно-зависимого кода.
Для оптимального функционирования базы данных необходимо будет
правильно определить логические взаимосвязи между таблицами. Таким образом,
на разработку самой базы данных и основы клиентского приложения может быть
затрачено значительное время.
Точно определив, какие именно данные нам нужны, каким образом они
будут храниться в памяти и какая должна быть система доступа к данным, мы тем
самым решили только вопрос управления данными. Кроме этого нужен еще
простой способ автоматизации решения предстоящих типовых задач.
Для выбора СУБД выделены несколько групп критериев:
Моделирование данных
Особенности архитектуры и функциональные возможности
Контроль работы системы
Особенности разработки приложений
Производительность
Надежность
Требования к рабочей среде
Смешанные критерии
Основным принципом выбора СУБД следует считать определение
программного продукта, в наибольшей мере соответствующего предъявляемым
требованиям. Эту задачу решить не очень просто. Во-первых, к СУБД
предъявляется большое число требований, которые с течением времени
изменяются, во-вторых, СУБД имеют большое число параметров, что затрудняет
их сравнение. Кроме того, информация о СУБД часто носит рекламный характер,
не позволяющий сделать правильное суждение.
На уровне технических характеристик разнообразие СУБД еще больше,
чем на качественном уровне. К техническим характеристикам относятся:
общие параметры (операционная среда, потребность в оперативной
памяти, ограничения на максимальный объем БД и др.);
ограничения на операции над данными;
53
типы данных;
возможности средств формулировки и выполнения запросов;
работа в многопользовательских средах;
инструментальные средства разработки приложений.
Оценка производительности производится методом тестирования с
помощью эталонных тестов из набора AS3AP (ANSI SQL Standard Scalable and
Portable). В них контролируется широкий спектр часто встречающихся операций
БД и моделируются однопользовательские и многопользовательские среды.
В Таблице 1.7 приведена сравнительная таблица трех распространенных
систем управления базами данных, конкурирующих на рынке программного
обеспечения по основным показателям.
Таблица 1.7
Сравнение СУБД
Факторы
(показатели)
Microsoft
SQL
Server
vNext
MySQL
5.7
PostgreSQL
10.2
Вес каждого фактора
Производительность
0,8
0,6
0,5
0,33333333
Защищенность
0,7
0,8
0,6
0,26666667
Простота
использования
0,2
0,9
0,3
0,2
Наличие
графического
средства
проектирования
0,7
0,9
0,4
0,13333333
Поддержка ОС
0,2
0,9
0,5
0,06666667
Итого
2,6
4,1
2,3
1
Рассчитывая обобщенный показатель качества фактора, получаем
результаты выбора в таблице 1.7.
Таблица 1.8
Второй этап выбора СУБД
Фактор
ы
(показат
ели)
Производител
ьность
Защищен
ность
Простота
использов
ания
Наличие
графическ
ого
средства
проектиро
вания
Поддер
жка ОС
Ито
го
54
MySQL
5.1
0,72
0,56
0,04
0,42
0,16
1,9
Microsof
t SQL
Server
2008
0,56
0,04
0,42
0,16
0
1,18
PostgreS
QL 8.4
0,04
0,42
0,16
0
0
0,62
Таким образом, для проекта, описывающего разработку ИС регистрации
заявок, наиболее приемлема СУБД MySQL.
1.4.3 Обоснование проектных решений по техническому обеспечению
Техническое обеспечение — комплекс технических средств,
предназначенных для работы информационной системы, а также
соответствующая документация на эти средства и технологические процессы
[16].
Комплекс технических средств составляют:
• компьютеры любых моделей;
• устройства сбора, накопления, обработки, передачи информации;
• устройства вывода информации;
• устройства передачи данных и линий связи;
• оргтехника и устройства автоматического съема информации;
• эксплуатационные материалы и др.
Разрабатываемый программный продукт имеет клиент-серверную
архитектуру.
Архитектура клиент-сервер основана на распределении функций между
двумя типами независимых и автономных процессов: серверами и клиентами.
Сеть связывает воедино серверы и клиенты, предоставляя средства связи.
Если вся обработка данных происходит на стороне сервера, а клиент
выполняет только функции интерфейса с пользователем, то клиентское
55
приложение называют «тонким» клиентом. Если часть обработки данных
происходит на стороне клиента — то «толстым» клиентом.
Архитектура клиент-сервер включает в себя три основных компонента:
Клиенты. Клиент представляет собой любой процесс компьютера, который
запрашивает сервис от сервера. Клиент также называется интерфейсным
приложением. Клиентский процесс, базируется на графическом интерфейсе
пользователя.
Серверы. Сервер — это компьютерный процесс, предоставляющий сервис
клиентам. Сервер также называют серверным приложением. Серверный процесс
характеризуется независимостью от местоположения, оптимизацией
использования ресурсов, масштабируемостью и способностью к взаимодействию
с другими системами.
Для корректного взаимодействия компонентов клиент-серверной
архитектуры между собой требуется их соответствие некоторым основным
правилам. Эти правила должны в равной степени выполнять и клиенты, и
серверы, и ППО.
Технические характеристики используемых в компании персональных
компьютеров относятся к компьютерам со средней производительностью, откуда
можно сделать вывод, что их модернизация или замена в целях выполнения
поставленной задачи не требуется.
Технические характеристики серверов также не подлежат улучшению, так
как в настоящее время используемые модели серверов имею возможность
нарастить свою производительность для выполнения автоматизируемой задачи
без ущерба для других выполняемых ими задач.
56
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл (ЖЦ) информационной системы - период времени,
который начинается с момента принятия решения о необходимости создания ИС
и заканчивается в момент ее полного изъятия из эксплуатации.
Ниже приведено описание основных стандартов жизненного цикла:
ГОСТ 34.601-90 – стандарт распространяется на автоматизированные
системы и определяет стадии и этапы их создания. Также в стандарте содержится
описание состава работ по каждому этапу.
ISO 12207 – стандарт устанавливает общую структуру процессов
жизненного цикла. Так же определяет процессы, работы и задачи, которые
используются: при приобретении системы в целом или отдельного программного
продукта; при оказании программной услуги, а также при поставке, разработке,
эксплуатации и сопровождении программных продуктов.
Oracle CDM (Custom Development Method) - стандарт по разработке
прикладных ИС, детализированный до уровня заготовки проектной
документации. Стандарт применяется при разработке с применением Oracle и
рекомендуется в случае малых проектов.
RUP (Rational Unified Process) – предполагает итеративную модель
разработки согласно четырем фазам: начало, исследование, построение и
внедрение. Каждая фаза может подразделяться на этапы, в результате выполнения
которых выпускается версия для внутреннего или внешнего использования.
MSF (Microsoft Solution Framework) – стандарт, сходный с RUP. Включает в
себя четыре фазы: анализ, проектирование, разработка и стабилизация. Также как
и RUP предполагает итеративную модель с использованием объектно-
ориентированного моделирования. MSF в отличии от RUP ориентирована более
на разработку бизнес-приложений.
XP (Extreme Programming) – стандарт «экстремальное программирование»
разработан в 1996 года, в его основе лежат следующие принципы: командная
57
работа, эффективная коммуникация между заказчиком и исполнителем и также
ведение разработок с использованием последовательно дорабатываемых
прототипов.
Для реализации проектного решения, необходимо первоначально выделить
основные этапы жизненного цикла будущей системы. Из всех имеющихся
стандартов, наиболее оптимальным будет ISO 12207 [2]. Выбор пал именно на
этот стандарт, в связи со следующими факторами: Во-первых, стандарт четкое не
регламентирует последовательность процессов в каждом этапе, что позволяет
самостоятельно выбирать подходящие для себя процессы. Во-вторых, стандарт
охватывает все этапы более полно, нежели остальные стандарты. В-третьих, ISO
12207 не указывает на этапы, а лишь регламентирует их, что позволит
разработчику самостоятельно управлять жизненным циклом.
Стандарт ISO 12207 включает всего 16 процессов, которые объединяются в
3 группы (рисунок 2.1).
3.1 Управление 3.2 Создание инфраструктуры
3.3 Усовершенствование 3.4 Обучение
1.1 Заказ
1.2 Поставка
1.4 Эксплуатация
1.3 Разработка
1.5
Сопровождение
2.1 Документирование
2.2 Управление конфигурацией
2.3 Обеспечение качества
2.4 Верификация
2.5 Совместный анализ
2.6 Аудит
2.7 Решение проблем
1. Основные процессы жизненного
цикла
3. Организационные процессы жизненного цикла
2. Вспомогательные процессы
жизненного цикла
Рисунок 2.1 Структура стандарта ISO 12207-99
Процессы состоят из отдельных видов деятельности. Всего стандартом
определенно 74 вида деятельности, связанной с разработкой и поддержкой ПО.
Каждый вид деятельности в свою очередь нацелен на выполнение одной или
нескольких задач.
58
Основной процесс жизненного цикла состоит из пяти видов деятельности:
1) Заказ;
2) Поставка;
3) Разработка;
4) Эксплуатация;
5) Сопровождение.
Каждый процесс определяет основного исполнителя и действия, которые
необходимо выполнить в назначенные сроки. Процесс заказа – основной
исполнитель организация заказчик информационной системе. На данном этапе
определяется потребность заказчика в информационной системе, происходит
выбор поставщика / разработчика и непосредственно управление заказом вплоть
до приемки готовой системы.
Процесс поставки – исполнитель организация поставщик. Этап начинается
с подписания договора на поставку системы, продолжается определением
процедур и ресурсов, необходимых для обеспечения выполнения проекта. И
заканчивается поставкой готовой системы и подписанием актов.
За процесс разработки отвечает организация разработчик. Процесс
включает в себя работы по анализу требований, проектированию,
программированию, сборке, тестированию и вводу в действия программного
продукта.
Процесс эксплуатации определяет задачи оператора. Он охватывает
эксплуатацию программного продукта и поддержку пользователей в процессе его
использования.
Процесс сопровождения состоит из задач и работы персонала,
ответственного за сопровождение программного продукта. Этот процесс
реализуется при модификациях программного продукта и документации к нему,
вызванных изменениями в связи с улучшением или устранением ошибок. Целью
процесса является изменение существующего программного продукта при
сохранении его целостности.
Согласно выбранному стандарту следует выделить следующие этапы:
Подготовка проекта
59
• Анализ деятельности
• Проведение предпроектного обследования
• Разработка плана проекта
Разработка
• Создание таблиц и связей БД
• Создание шаблонов отчетных файлов
• Создание процедур по сбору, обработке и хранению информации
• Создание процедур фильтрации
• Разработка пользовательского интерфейса
Тестирование настроек системы
• Настройка словарей и справочников
• Тестирование работоспособности системы
• Корректировка системы по результатам тестирования
• Подготовка документации для внедрения
• План эксплуатации
• Документация по установки и настройки ПО
• Подготовка плана внедрения
Внедрение
• Установка на сервер СУБД
• Установка серверных компонентов системы учета заявок
• Установка клиентских приложений системы учета заявок
• Настройка серверной и клиентских частей
• Тестирование работоспособности
• Демонстрация работы системы
• Подготовка плана по обучению пользователей
• Проведение семинара по обучению работе с системой
• Обучение службы эксплуатации
Эксплуатация
• Подготовка плана по эксплуатации
• Ввод системы в опытную эксплуатацию
60
• По результатам опытной эксплуатации перевод системы в
промышленную эксплуатацию
• Поддержка пользователей
• Проведение обучающих лекция для пользователей
• Подготовка отчетов о работе системы
Сопровождение
• Анализ ошибок и их устранение
• Подготовка отчетов по модификациям и изменениям
• Обновление функционирующих систем
На первоначальном этапе после проведения анализа деятельности
организации, необходимо поставить цели и задачи автоматизации и разработать
план проекта. После документального оформления начинается непосредственно
сам процесс разработки. Создается база данных, отчетные формы, пишется
программный код по сбору, обработке и хранению информации, создаются
процедуры фильтрации. После разработки системы, проходит этап тестирования.
По завершению тестирования готовится план эксплуатации и документация для
внедрения, а так же различная пользовательская документация. Процесс будет
происходить следующим образом. Так как в организации уже существует ЛВС и
стабильно функционирует, в ее наладке нет необходимости. Первоначально
устанавливается серверная часть системы учета заявок, далее на рабочие места
проходит установка и настройка клиентских приложений системы учета заявок и
СУБД. Тестируется работоспособность, проводится демонстрация работы
системы для руководства и персонала. Последней стадией будет проведение
семинаров для сотрудников компании. Необходимо связать всех сотрудников,
отвечающих за обработку документов в единую информационную сеть. Для этого
клиентские приложения будут устанавливаться в четкой последовательности по
определенным отделам
За эксплуатацию готовой системы, будет отвечать оператор. В его задачу
будет входить:
1. Разработка плана эксплуатации и определения набора стандартов
эксплуатации.