56
которого клиенты и серверы взаимодействуют друг с другом. Это ПО называют еще
уровнем коммуникаций. ППО обычно привязано к сети. Все клиентские запросы и
ответы сервера передаются по сети в форме сообщений, в которых содержатся
управляющая информация и данные.
Клиентский процесс, базирующийся на графическом интерфейсе
пользователя, запрашивает сервисы у серверного приложения. Клиентский процесс
и серверный процесс взаимодействуют при помощи промежуточного программного
обеспечения (ППО).
Клиентский процесс посылает SQL-запрос через коммуникационное ППО.
Коммуникационное ППО направляет SQL-запрос процессу сервера БД. Процесс
сервера БД получает запрос, проверяет его и выполняет.
ППО гарантирует, что сообщения между клиентами и серверами будут
правильно маршрутизоваться и доставляться по нужному адресу.
Для корректного взаимодействия компонентов клиент-серверной архитектуры
между собой требуется их соответствие некоторым основным правилам. Эти
правила должны в равной степени выполнять и клиенты, и серверы, и ППО.
Эксплуатация разрабатываемой системя должна производиться на рабочих
станциях следующей конфигурации:
операционная система — Linux, Windows, FreeBSD, Mac OS X, Solaris;
процессор — Pentium/Celeron/Athlon 1000-1800 МГц;
память (ОЗУ) — 1024 Мб;
жесткий диск — не менее 200 МБ свободного места (для установки
программного обеспечения);
монитор — позволяющий работать с разрешением экрана не менее
1152x864 пикселей;
устройства ввода информации (клавиатура, мышь);
дополнительное программное обеспечение — Oracle Java SE Runtime
Environment (JRE) 7.
Однако для сервера баз данных понадобится более мощное техническое
обеспечение:
операционная система — FreeBSD, Linux, Mac OS X, Solaris, Windows
Server;
57
процессор — Pentium/Celeron/Athlon 2400-3000 МГц;
память (ОЗУ) — 2024-3072 Мб;
жесткий диск — определяется объемом базы данных;
устройства ввода информации (клавиатура, мышь).
Выводы по главе 1
В первой главе работы проведен анализ деятельности компании, описана ее
программная и техническая архитектура, выбран процесс , подлежащий
автоматизации, приняты решения по основным видам обеспечения информационной
системы, в том числе программному, техническому и информационному, что
позволяет непосредственно перейти в разработке информационной системы.
58
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл определяется как непрерывный процесс, который обычно
начинается с момента принятия решения о важности его реализации и заканчивается
сразу же после его изъятия из эксплуатации.
Среди наиболее популярных стандартов обычно выделяют следующие:
• ГОСТ 34.601-90 – применим к автоматизированным системам и
устанавливает все стадии и этапы их разработки. Также в этом стандарте есть
описание содержания работ для каждого этапа. Этапы и стадии, которые закреплены
в данном стандарте, чаще всего соответствуют каскадной модели жизненного цикла.
• ISO/IEC 12207 – стандарт, определяющий процессы и организацию
жизненного цикла. Применим к любому виду заказного ПО. В стандарте нет
описания стадий, фаз и этапов.
• Custom Development Method (Oracle) – технологический материал по
разработке прикладных ИС, который детализирован до уровня заготовок проектных
инструкций, которые будут использоваться в проектах с участием Oracle.
Используется CDM для классической модели ЖЦ (имеются все этапы и задачи), а
также при технологии быстрой разработки или облегченного прохода, которые
используются в случае малого проекта.
• Rational Unified Process (RUP) – использует некую интерактивную
модель разработки, которая включает 4 фазы: начало, исследование, построение и
внедрение. Любая из этих фаз может разбиваться на этапы, в результате которых
исполняется версия для внутреннего или внешнего использования. Проход по всем 4
фазам – это цикл разработки, и каждый такой цикл завершается генерацией версии
системы. Если после этого проект продолжается, то сам продукт также
видоизменяется и проходит эти фазы еще раз. Суть работы в рамках RUP -
разработки и сопровождение моделей на базе UML.
• Microsoft Solution Framework (MSF) – поход на RUP, также имеет 4
фазы: анализ, проектирование, разработка и стабилизация, является итерационным и
59
предполагает применение объектно-ориентированных моделей. MSF в сравнении с
RUP в большей степени предназначен для создания бизнес-приложений.
• Extreme Programming (XP) – экстремальное программирование
(новейшая методология, сформировалась в 96 году). Основу методологии
составляют командная работы, активная коммуникация с заказчиком в течение всего
проекта по созданию ИС, ведение разработки с применением последовательно
обрабатываемых прототипов.
Для выбора стандарта основным фактором будет являться более подробное и
полное описание работы на стадиях и этапах разработки АС.
Стандарт ISO/IEP 12207 не имеет подробного описания работы на разных
стадиях и этапах создания АС.
Стандарт CDM рассчитан на проекты с использованием Oracle-технологий,
которые не применяются в данном проекте.
Стандарт MSF, как было сказано выше, ориентирован на бизнес-сферу.
Стандарт XP больше рассчитан на команду. Поэтому в данном проекте
используется ГОСТ 34.601-90, поскольку именно у него есть описание работы на
каждом этапе разработки АС.
Базовыми стадиями создания АС являются:
1) Выведение требований к системе;
2) Создание концепции;
3) Написание ТЗ;
4) Составление технического проекта;
5) Подготовка документации;
6) Внедрение.
Спиральная модель воплощает в себе преимущества каскадной модели. При
этом в нее также включены анализ рисков, управление ими, а также процессы
поддержки и менеджмента. Здесь также предусмотрена разработка программного
продукта при использовании метода прототипирования или быстрой разработки
приложений посредством применения языков программирования и средств
разработки четвертого поколения (и выше).
На основании описания моделей разработки выбираем спиральную модель.
Ниже приведено описание основных стандартов жизненного цикла:
60
ГОСТ 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 года, в его основе лежат следующие принципы: командная работа,
эффективная коммуникация между заказчиком и исполнителем и также ведение
разработок с использованием последовательно дорабатываемых прототипов.
Для реализации проектного решения, необходимо первоначально выделить
основные этапы жизненного цикла будущей системы. Из всех имеющихся
стандартов, наиболее оптимальным будет ISO 12207 -99 [2]. Выбор пал именно на
этот стандарт, в связи со следующими факторами: Во-первых, стандарт четкое не
регламентирует последовательность процессов в каждом этапе, что позволяет
самостоятельно выбирать подходящие для себя процессы. Во-вторых, стандарт
охватывает все этапы более полно, нежели остальные стандарты. В-третьих, ISO
61
12207-99 не указывает на этапы, а лишь регламентирует их, что позволит
разработчику самостоятельно управлять жизненным циклом.
Стандарт 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 вида деятельности, связанной с разработкой и поддержкой ПО.
Каждый вид деятельности в свою очередь нацелен на выполнение одной или
нескольких задач.
Основной процесс жизненного цикла состоит из пяти видов деятельности:
1) Заказ;
2) Поставка;
3) Разработка;
4) Эксплуатация;
5) Сопровождение.
Каждый процесс определяет основного исполнителя и действия, которые
необходимо выполнить в назначенные сроки. Процесс заказа – основной
исполнитель организация заказчик информационной системе. На данном этапе
определяется потребность заказчика в информационной системе, происходит выбор
62
поставщика / разработчика и непосредственно управление заказом вплоть до
приемки готовой системы.
Процесс поставки – исполнитель организация поставщик. Этап начинается с
подписания договора на поставку системы, продолжается определением процедур и
ресурсов, необходимых для обеспечения выполнения проекта. И заканчивается
поставкой готовой системы и подписанием актов.
За процесс разработки отвечает организация разработчик. Процесс включает
в себя работы по анализу требований, проектированию, программированию, сборке,
тестированию и вводу в действия программного продукта.
Процесс эксплуатации определяет задачи оператора. Он охватывает
эксплуатацию программного продукта и поддержку пользователей в процессе его
использования.
Процесс сопровождения состоит из задач и работы персонала, ответственного
за сопровождение программного продукта. Этот процесс реализуется при
модификациях программного продукта и документации к нему, вызванных
изменениями в связи с улучшением или устранением ошибок. Целью процесса
является изменение существующего программного продукта при сохранении его
целостности.
Согласно выбранному стандарту следует выделить следующие этапы:
Подготовка проекта
• Анализ деятельности
• Проведение предпроектного обследования
• Разработка плана проекта
Разработка
• Создание таблиц и связей БД
• Создание шаблонов отчетных файлов
• Создание процедур по сбору, обработке и хранению информации
• Создание процедур фильтрации
• Разработка пользовательского интерфейса
Тестирование настроек системы
• Настройка словарей и справочников
• Тестирование работоспособности системы
63
• Корректировка системы по результатам тестирования
• Подготовка документации для внедрения
• План эксплуатации
• Документация по установки и настройки ПО
• Подготовка плана внедрения
Внедрение
• Установка на сервер СУБД
• Установка серверных компонентов системы учета продаж
• Установка клиентских приложений системы учета продаж
• Настройка серверной и клиентских частей
• Тестирование работоспособности
• Демонстрация работы системы
• Подготовка плана по обучению пользователей
• Проведение семинара по обучению работе с системой
• Обучение службы эксплуатации
Эксплуатация
• Подготовка плана по эксплуатации
• Ввод системы в опытную эксплуатацию
• По результатам опытной эксплуатации перевод системы в
промышленную эксплуатацию
• Поддержка пользователей
• Проведение обучающих лекция для пользователей
• Подготовка отчетов о работе системы
Сопровождение
• Анализ ошибок и их устранение
• Подготовка отчетов по модификациям и изменениям
• Обновление функционирующих систем
На первоначальном этапе после проведения анализа деятельности
организации, необходимо поставить цели и задачи автоматизации и разработать
план проекта. После документального оформления начинается непосредственно сам
процесс разработки. Создается база данных, отчетные формы, пишется
программный код по сбору, обработке и хранению информации, создаются
64
процедуры фильтрации. После разработки системы, проходит этап тестирования. По
завершению тестирования готовится план эксплуатации и документация для
внедрения, а так же различная пользовательская документация. Процесс будет
происходить следующим образом. Так как в организации уже существует ЛВС и
стабильно функционирует, в ее наладке нет необходимости. Первоначально
устанавливается серверная часть системы учета продаж, далее на рабочие места
проходит установка и настройка клиентских приложений системы учета продаж и
СУБД. Тестируется работоспособность, проводится демонстрация работы системы
для руководства и персонала. Последней стадией будет проведение семинаров для
сотрудников компании. Необходимо связать всех сотрудников, отвечающих за
обработку документов в единую информационную сеть. Для этого клиентские
приложения будут устанавливаться в четкой последовательности по определенным
отделам
За эксплуатацию готовой системы, будет отвечать оператор. В его задачу
будет входить:
1. Разработка плана эксплуатации и определения набора стандартов
эксплуатации.
2. Получение и документирование сведений о возникающих проблемах, их
решение и контроль за возникновением, обеспечение обратной связи с
пользователями.
3. Тестирование системе в эксплуатационной среде, кооперация со службой
сопровождения для устранения возникших проблем и модернизации системы.
4. Поддержка и консультация пользователей.
В соответствии с выбранной моделью основными этапами разработки будут
являться:
Формирование требований
Проектирование
Реализация
Тестирование
Ввод в действие
Эксплуатация и сопровождение.
Существует 4 основных способа начала использования новой системы
65
Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация "пилотного проекта.
Параллельная стратегия не подходит , так как компания не располагает
достаточными ресурсами для ведения учета одновременно в автоматизированном и
ручном вариантах. Стратегия Скачек не позволяет плавно перейти на использование
разработки, узкое место больше подходит для использования в крупных компаниях.
Поэтому в качестве стратегии внедрения ИС была выбрана «Опытная эксплуатация
пилотного проекта».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Проект разработки информационной системы автоматизации
деятельности турагенства, как любой другой проект разработки программного
обеспечения, содержит в себе много неопределенных моментов, которые
влекут за собой риски реализации проекта.
Управление рисками заключается в их раннем выявлении и разработке
мер либо полностью предотвращающих их возникновение, либо
минимизирующих их последствия.
В настоящее время существует три общепринятых стратегии управления
рисками:
Избегание рисков – проект реорганизуется таким образом, чтобы
исключить возможность возникновения рисков;
Делегирование рисков – проект реорганизуется таким образом,
чтобы переложить риски на третью сторону (заказчика, банки, вендора и т.п.);
Принятие рисков – риски признаются в качестве неизбежной
составляющей проекта, проводится постоянный мониторинг симптомов их
наступления, постоянно корректируется план действий в случае наступления
рисков.