61
сети, что зачастую резко нагружает сеть и, как результат, снижает
быстродействие ПО при росте числа работающих сразу клиентов.
Также к недостаткам самой архитектуры сервера можно отнести
децентрализованное решение реализуемых проблем полноценность и
неизменности данных, а также их доступности. Такое решение явно
минимизирует стабильность приложения.
Клиент-серверная архитектура сводит на нет все указанные недостатки.
т.к. она позволяет лучшим образом разделять нагрузки между клиентом и
сервером, что оказывает явное влияние на системы в целом: поддержку, цену и
скорость работы.
К примеру, подобная архитектура помогает поддержать дополнительную
надежность и стабильность системы, роста мощности системы и числа активных
подключений за счет применения нескольких серверных приложений. Также
доступен перенос БД с одной СУБД на другую и корректировка требуемых
данных без частого обновления клиентских программ. Сервер приложений еще
и явно минимизирует нагрузку на сервер БД.
Самый правильный шаг для решения выбранной задачи становится
внедрение архитектуры тонкого клиента и толстого сервера, т.к. 3 звена в
архитектуре не требуются для текущей задачи, а цена и сложность реализации
подобной сложной архитектуры явно больше, чем 2-уровневой. Да и при том,
текущая информационная инфраструктура без проблем подойдет только для 2-
уровневой архитектуры.
Для корректного взаимодействия компонентов клиент-серверной
архитектуры между собой требуется их соответствие некоторым основным
правилам. Эти правила должны в равной степени выполнять и клиенты, и
серверы, и ППО.
Эксплуатация разрабатываемой системы должна производиться на
рабочих станциях следующей конфигурации:
операционная система — Windows;
процессор — Pentium/Celeron/Athlon 1000-1800 МГц;
62
память (ОЗУ) — 1024 Мб;
жесткий диск — не менее 200 МБ свободного места (для установки
программного обеспечения);
монитор — позволяющий работать с разрешением экрана не менее
1152x864 пикселей;
устройства ввода информации (клавиатура, мышь);
дополнительное программное обеспечение — Oracle Java SE Runtime
Environment (JRE) 7.
Однако для сервера баз данных понадобится более мощное техническое
обеспечение:
операционная система — FreeBSD, Linux, Mac OS X, Solaris,
Windows Server;
процессор — Pentium/Celeron/Athlon 2400-3000 МГц;
память (ОЗУ) — 2024-3072 Мб;
жесткий диск — определяется объемом базы данных;
устройства ввода информации (клавиатура, мышь).
63
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
ЖЦ любой ИС выступает неким сбором событий, которые происходят с
системой от начала использования до вывода из эксплуатации.
Модель ЖЦ показывает разные состояния системы от этапа необходимости
данной ИС и до момента завершения ее обслуживания. Модель ЖЦ является
некой структурой, включающей в себя процессы, действия и задачи, которые
происходят в рамках создания, поддержки ПО в период жизни системы, от
понимания требований до прекращения использования.
Есть несколько моделей ЖЦ [29]:
Каскадная модель, которая подразумевает периодическую
реализацию всех этапов проекта в утвержденном ранее порядке. Работа над
следующим этапом говорит о полном завершении всех работ предыдущего.
Поэтапная модель с контролем в периодах. Реализация ИС
происходит в рамках итерации с циклами обратной связи каждого этапа.
Межэтапные проверки помогают выявить имеющиеся взаимовлияние итогов
создания на каждом этапе; ЖЦ любого этапа идет до окончания разработки.
Спиральная модель. Каждый виток спирали генерирует новую
версию продукта, корректирует требования к проекту, отражает его качество и
составляет план работ на новый виток. Важную роль тут играет начальный этап
разработки – проект и анализ, где доступность реализации тех или иных
вариантов обосновывается и утверждается методом создания прототипов.
Каскадный подход замечательно подойдёт для создания относительно
простых ИС, когда еще в начале разработке описаны и составлены все
требования к системе. Основным минусом подобного подхода назовем то, что
базовый процесс создания системы не укладывается в данные жесткие рамки,
нужно всегда возвращаться к уже завершенным этапам для корректировки
64
принятых и реализованных решений. В итоге сам процесс разработки ИС часто
соответствует поэтапной модели с периодичным контролем.
ЖЦ является постоянным процессом, который наступает с момента выбора
решения о необходимости его реализации и останавливается в момент его
изъятия из пользования.
Наиболее известные на сегодня стандарты:
1. ГОСТ 34.601-90 – направлен на АИС и описывает стадии и этапы
процесса их создания;
2. ISO/IEC 12207 – стандарт процессов и реализации ЖЦ. Направлен на
все виды реализуемого ПО под заказ. Не имеет внутри себя фаз, стадий и этапов;
3. Custom Development Method по реализации прикладных ИС –
технологический материал, описанный до момента подготовки проектных
документов, которые предполагают применение на проектах с технологиями
Orаcle;
4. Rаtionаl Unified Process (RUP) включает итеративную модель
проектирования, имеющую 4 фазы: начало проекта, процесс анализа, реализация
и использование. Сущность действия в рамках RUP - это создание и поддержка
моделей в рамках UML [2];
аmework (MSF) похожа на RUP, включает те же 4 фазы: понимание, реализация,
подготовка, проверка, сама по себе итерационна, включает применение ООП.
MSF относительно RUP изначально направлена на внедрение бизнес-
приложений; 6. Extreme Progrаmming (XP) – особый подход к программированию.
Основой методики становится командная работа, наилучшая коммуникация
заказчика и изготовителя в течение всего проекта реализации ИС, по итогу сам
процесс проектирования идет при помощи последовательно обновляемых
прототипов [15].
В рамках определение стандарта основным фактором становится понятное
и подробное описание работ на всех шагах реализации АС.
65
Стандарт ISO/IEC 12207 не включает полного описания работ на всех
этапах реализации АС [41].
Стандарт CDM используется в работах с включением Orаcle-технологий, а
в нашем проекте их нет.
Стандарт MSF, опираясь на сказанное ранее, часто направлен на внедрение
бизнес-приложений.
Стандарт XP актуален для командной работы.
В данной работе применяется ГОСТ 34.601-90, т.к. он включает описание
работ на каждом этапе разработки АС.
Главные стадии создания ИС: 1) Описание требований к системе, 2)
Описание концепции; 3) Подготовка ТЗ; 4) Написание тех. проекта 5) Подготовка
документов; 6) Инсталляция.
Исходя из известных моделей выделим некоторые модели ЖЦ АИС —
каскадную, итерационную и спиральную [4].
Стандарт ISO 12207 включает всего 16 процессов, которые объединяются
в 3 группы (рисунок 9).
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. Вспомогательные процессы
жизненного цикла
Рисунок 9. Структура стандарта ISO 12207-99
66
Процессы состоят из отдельных видов деятельности. Всего стандартом
определенно 74 вида деятельности, связанной с разработкой и поддержкой ПО.
Каждый вид деятельности в свою очередь нацелен на выполнение одной или
нескольких задач.
Основной процесс жизненного цикла состоит из пяти видов деятельности:
Заказ;
Поставка;
Разработка;
Эксплуатация;
Сопровождение.
Каждый процесс определяет основного исполнителя и действия, которые
необходимо выполнить в назначенные сроки. Процесс заказа – основной
исполнитель организация заказчик информационной системе. На данном этапе
определяется потребность заказчика в информационной системе, происходит
выбор поставщика / разработчика и непосредственно управление заказом вплоть
до приемки готовой системы.
Процесс поставки – исполнитель организация поставщик. Этап начинается
с подписания договора на поставку системы, продолжается определением
процедур и ресурсов, необходимых для обеспечения выполнения проекта. И
заканчивается поставкой готовой системы и подписанием актов.
За процесс разработки отвечает организация разработчик. Процесс
включает в себя работы по анализу требований, проектированию,
программированию, сборке, тестированию и вводу в действия программного
продукта.
Процесс эксплуатации определяет задачи оператора. Он охватывает
эксплуатацию программного продукта и поддержку пользователей в процессе его
использования.
Процесс сопровождения состоит из задач и работы персонала,
ответственного за сопровождение программного продукта. Этот процесс
реализуется при модификациях программного продукта и документации к нему,
67
вызванных изменениями в связи с улучшением или устранением ошибок. Целью
процесса является изменение существующего программного продукта при
сохранении его целостности.
Исходя их описанного выше стандарта, выделим несколько этапов
разработки АСУ [32]:
Начало проекта:
o Исследование работы;
o Выполнение предпроектного анализа;
o Подготовка плана проекта.
Создание:
o Разработка таблиц и связей БД;
o Разработка шаблонов отчетных файлов;
o Внедрение процедур по получению, хранению и анализу
информации;
o Подготовка процедур фильтрации;
o Создание интерфейса пользователя.
Тестирование работы системы:
o Отладка словарей и справочников;
o Проверка работоспособности системы;
o Исправление системы по итогам проверки;
o Написание документации для внедрения;
o Подготовка плана эксплуатации;
o Написание документов по установке и настройке ПО;
o Создание плана внедрения.
Установка:
o Инсталляция на сервер СУБД;
o Инсталляция серверных модулей системы учета продаж;
o Инсталляция клиентских модулей системы учета продаж;
o Отладка серверной и клиентских частей;
o Проверка работы системы;
68
o Представление работы системы;
o Организация плана по проведению обучения пользователей;
o Планирование семинара по обучению работе с системой;
o Представление системы службе эксплуатации.
Использование:
o Подготовка плана использования;
o Ввод системы в рабочий режим;
o Перевод системы в промышленную эксплуатацию по итогу
тестирования;
o Реализация поддержки пользователей;
o Обучение для пользователей;
o Генерация отчетов по работе системы;
Управление:
o Нахождение и устранение ошибок;
o Генерация отчетов по обновлениям и изменениям;
o Модернизация функционирующих систем.
Изначально после проведения анализа работы компании, важно поставить
цели и задачи автоматизации и подготовить план проекта [33]. После создания
документов начинается сам процесс реализации. Создается БД, отчетные формы,
программируются алгоритмы по сбору, анализу, хранению данных, реализуются
процедуры фильтрации. По факту создания системы, начинается этап
тестирования. По итогам тестирования получается план эксплуатации и
документация для установки, а также дополнительная пользовательская
документация. Процесс происходит так: поскольку в компании есть текущая
ЛВС и работает он нормально, в ее наладке необходимости нет. Изначально
запускается серверная часть системы учета продаж, позже на рабочие места
ставится и настраивается клиентская часть системы учета продаж и СУБД.
Проверяется работоспособность, показывается работа системы персоналу и
руководству. Финальной стадией становится реализация семинаров для
персонала компании. Важно объединить всех сотрудников, которые отвечают за
69
анализ документов в единую ИС. Для этого клиентские приложения ставятся в
строго оговоренной последовательности по нужным отделам [34].
За поддержку готовой отвечает оператор. В его обязанности будет
включено:
Подготовка плана эксплуатации и отражения набора стандартов
эксплуатации;
Документирование сведений по текущим проблемам, их решение и
контроль за работой, обеспечение обратной связи с клиентами;
Проверка системе в среде работы, взаимодействие со службой
сопровождения для минимизации возникших проблем и обновлений системы;
Консультирование пользователей.
Для разработки системы была выбрана каскадную модель, так как она
позволяет работать над несколькими этапами разработки одновременно.
Существует 4 основных способа начала использования новой системы
Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация пилотного проекта.
Стратегия «Опытная эксплуатация пилотного проекта» не подходит, так
как компания не располагает достаточными ресурсами для длительной
эксплуатации проекта с целью выявления всех возможных ошибок. Стратегия
Скачек не позволяет плавно перейти на использование разработки, узкое место
больше подходит для использования в крупных компаниях. Поэтому в качестве
стратегии внедрения информационной системы выбираем параллельную
стратегию, то есть разработанная информационная система будет использоваться
параллельно с используемой технологией до полного вытеснения последней.
Исходя их описанного выше стандарта, выделим несколько этапов
разработки АСУ [32]:
Начало проекта:
o Исследование работы;
70
o Выполнение предпроектного анализа;
o Подготовка плана проекта.
Создание:
o Разработка таблиц и связей БД;
o Разработка шаблонов отчетных файлов;
o Внедрение процедур по получению, хранению и анализу
информации;
o Подготовка процедур фильтрации;
o Создание интерфейса пользователя.
Тестирование работы системы:
o Отладка словарей и справочников;
o Проверка работоспособности системы;
o Исправление системы по итогам проверки;
o Написание документации для внедрения;
o Подготовка плана эксплуатации;
o Написание документов по установке и настройке ПО;
o Создание плана внедрения.
Установка:
o Инсталляция на сервер СУБД;
o Инсталляция серверных модулей системы учета продаж;
o Инсталляция клиентских модулей системы учета продаж;
o Отладка серверной и клиентских частей;
o Проверка работы системы;
o Представление работы системы;
o Организация плана по проведению обучения пользователей;
o Планирование семинара по обучению работе с системой;
o Представление системы службе эксплуатации.
Использование:
o Подготовка плана использования;
o Ввод системы в рабочий режим;