77
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Для адекватной работы АИС она включает в себя подсистемы
обеспечивающей части.
Среди обеспечивающих подсистем определяют информационное,
математическое, техническое программное, правовое и организационное
обеспечение.
ИО (информационное обеспечение) представляет собой совокупность
информационных ресурсов в распоряжение отдельного объекта или субъекта. ИО
АИС обычно состоит из внемашинного и внутримашинного ИО [25].
ТО (техническое обеспечение) представляет из себя комплекс технических
средств, необходимых для работы АИС, а также текущая документация на эти
техпроцессы и средства [21].
МО (математическое обеспечение) являются совокупностью математических
методов, алгоритмов, моделей и программ для создания целей, задач АИС, а также
адекватной работы совокупных технических средств.
ПО (программное обеспечение) считается совокупностью программ и
документов, которые нужны для нормальной работы [26].
ОО (организационное обеспечение) считается совокупностью средств и
методов, которые описывают действия работников с техническими средствами и
между собой в рамках внедрения и эксплуатации АИС [22].
Пр. О (правовое обеспечение) считается сводом правовых норм,
описывающих создание, юридический статус и работу АИС, определяющих
порядок получения, модернизации и применения данных.
АИС и ее составные части могут находиться в одном месте, если связь
между компонентами АИС (или частями 1 компонента) реализована посредством
каналов связи, то подобная АИС является распределенной.
78
ЖЦ является непрерывным процессом, начинающимся с момента
зарождения решения о важности его создания и заканчивающимся тогда, когда
продукт изымается из эксплуатации [23].
Самые распространенные стандарты, это: [1]:
• ГОСТ 34.601-90 – относится к АИС и устанавливает части и этапы их
создания. Также в нем описано содержание работ на любом этапе. Этапы и стадии
проекта, указанные в стандарте, зачастую соответствуют каскадной модели ЖЦ
[27].
• ISO/IEC 12207 - стандарт на процессы и реализацию ЖЦ. Относится
ко всем видам заказного ПО. Стандарт не включает описания фаз, этапов и стадий
[7].
• Custom Development Method от Oracle по созданию прикладных ИС -
технологический материал, разработанный до уровня шаблонов преоктных
документов, которые рассчитаны на применение в проектах, связанных с Oracle.
Используется CDM для стандартной модели ЖЦ (есть все задачи и типы), а также
для вариантов оперативной разработки (Fast Track) или простого подхода, которые
применяются в случае малых проектов [8].
• Rational Unified Process (RUP) описывает итеративную модель
разработки, состоящую из 4 фаз: начало, анализ, разработка и применение. Каждая
фаза делиться на этапы (итерации), по итогу которых выпускается версия для
применения внутри или вне [24]. Завершение всех 4 фаз считается циклом
разработки, каждый цикл по итогу представляет версию системы. Если после этого
проект не завершается, полученный продукт развивается дальше и проходит все
эти же фазы. Суть проекта в рамках RUP - это разработка и сопровождение
моделей на базе UML [37].
• Microsoft Solution Framework (MSF) схожа чем-то с RUP, имеет 4
фазы: анализ, подготовка, создание, тестирование, является итерационной, может
применять объектно-ориентированного моделирования. MSF в отличии от RUP
более ориентирована на создание бизнес-приложений [38].
• Extreme Programming (XP) - экстремальное программирование
(современная методология) была предложена в 1996 году. В базе методологии
командная работа, отличная коммуникация между исполнителем и заказчиком в
79
рамках выполнения всего проекта по созданию ИС, а сам процесс реализуется
посредством последовательно оптимизируемых прототипов [28].
В процессе подбора стандарта главным фактором становится полноценное и
подробное описание работ на этапах и стадиях разработки АИС.
Стандарт ISO/IEC 12207 не имеет полноценного описания работ на этапах и
стадиях создания АС.
Стандарт CDM применяется в проектах с Oracle технологиями, а в данном
проекте они не используются.
Стандарт MSF, исходя из описанного ранее, чаще всего ориентирован на
создание бизнес-приложений [8].
Стандарт XP относится к командной работе. В данном проекте применяется
ГОСТ 34.601-90, поскольку он включает описание работ на всех этапах создания
АС.
Главные этапы разработки ИС (рисунок 2):
1. Подготовка требований к системе;
2. Подготовка концепции;
3. Написание ТЗ;
4. Подготовка проекта;
5. Создание документов;
6. Применение.
На настоящий момент существуют такие модели жизненного цикла, как
каскадная, поэтапная с промежуточным контролем, спиральная.
В спиральной модели особое внимание уделяется начальным этапам
разработки – выработке стратегии, анализу и проектированию, где реализуемость
тех или иных технических решений проверяется и обосновывается посредством
создания прототипов (макетирования). Каждый виток спирали предполагает
создание фрагмента (компонента) или версии программного продукта. На них
уточняются цели и характеристики проекта, определяется его качество и
планируются работы следующего витка спирали. Таким образом углубляются и
последовательно конкретизируются детали проекта и в результате выбирается
обоснованный вариант, который доводится до реализации.
80
Для разрабатываемого проекта наиболее подойдет каскадная модель для
разработки приложения из-за возможности контроля промежуточных фаз.
Далее произведем выбор стратегии внедрения разработанной системы. В
настоящий момент выделяется четыре стратегии внедрения информационной
системы:
Параллельная стратегия - для случая, когда старую работающую
систему необходимо заменить новой;
Скачок – эта стратегия подразумевает резкий переход от одной
системы автоматизации к другой;
Опытная эксплуатация "пилотного проекта - это тактика "скачка", но
применяемая к ограниченному числу изделий, наиболее успешна в малом участке
деятельности;
Узкое место - при внедрении "узкого места" план внедрения
выполняется только для "узкого места" и для людей, работающих в нем.
Исходя из описания и условий деятельности компании, а также особенностей
разрабатываемой информационной системы, в качестве стратегии внедрения была
выбрана стратегия Опытная эксплуатация пилотного проекта, так как в этом случае
внедрение системы произойдет наиболее безболезненно.
Для реализации проектного решения, необходимо первоначально выделить
основные этапы жизненного цикла будущей системы. Из всех имеющихся
стандартов, наиболее оптимальным будет ISO 12207 -99 [2]. Выбор пал именно на
этот стандарт, в связи со следующими факторами: Во-первых, стандарт четкое не
регламентирует последовательность процессов в каждом этапе, что позволяет
самостоятельно выбирать подходящие для себя процессы. Во-вторых, стандарт
охватывает все этапы более полно, нежели остальные стандарты. В-третьих, ISO
12207-99 не указывает на этапы, а лишь регламентирует их, что позволит
разработчику самостоятельно управлять жизненным циклом.
Стандарт ISO 12207 включает всего 16 процессов, которые объединяются в 3
группы.
Процессы состоят из отдельных видов деятельности. Всего стандартом
определенно 74 вида деятельности, связанной с разработкой и поддержкой ПО.
81
Каждый вид деятельности в свою очередь нацелен на выполнение одной или
нескольких задач.
Основной процесс жизненного цикла состоит из пяти видов деятельности:
1) Заказ;
2) Поставка;
3) Разработка;
4) Эксплуатация;
5) Сопровождение.
Каждый процесс определяет основного исполнителя и действия, которые
необходимо выполнить в назначенные сроки. Процесс заказа – основной
исполнитель организация заказчик информационной системе. На данном этапе
определяется потребность заказчика в информационной системе, происходит
выбор поставщика / разработчика и непосредственно управление заказом вплоть до
приемки готовой системы.
Процесс поставки – исполнитель организация поставщик. Этап начинается с
подписания договора на поставку системы, продолжается определением процедур
и ресурсов, необходимых для обеспечения выполнения проекта. И заканчивается
поставкой готовой системы и подписанием актов.
За процесс разработки отвечает организация разработчик. Процесс включает
в себя работы по анализу требований, проектированию, программированию,
сборке, тестированию и вводу в действия программного продукта.
Процесс эксплуатации определяет задачи оператора. Он охватывает
эксплуатацию программного продукта и поддержку пользователей в процессе его
использования.
Процесс сопровождения состоит из задач и работы персонала,
ответственного за сопровождение программного продукта. Этот процесс
реализуется при модификациях программного продукта и документации к нему,
вызванных изменениями в связи с улучшением или устранением ошибок. Целью
процесса является изменение существующего программного продукта при
сохранении его целостности.
Согласно выбранному стандарту следует выделить следующие этапы:
Подготовка проекта
82
• Анализ деятельности
• Проведение предпроектного обследования
• Разработка плана проекта
Разработка
• Создание таблиц и связей БД
• Создание шаблонов отчетных файлов
• Создание процедур по сбору, обработке и хранению информации
• Создание процедур фильтрации
• Разработка пользовательского интерфейса
Тестирование настроек системы
• Настройка словарей и справочников
• Тестирование работоспособности системы
• Корректировка системы по результатам тестирования
• Подготовка документации для внедрения
• План эксплуатации
• Документация по установки и настройки ПО
• Подготовка плана внедрения
Внедрение
• Установка на сервер СУБД
• Установка серверных компонентов системы учета продаж
• Установка клиентских приложений системы учета продаж
• Настройка серверной и клиентских частей
• Тестирование работоспособности
• Демонстрация работы системы
• Подготовка плана по обучению пользователей
• Проведение семинара по обучению работе с системой
• Обучение службы эксплуатации
Эксплуатация
• Подготовка плана по эксплуатации
• Ввод системы в опытную эксплуатацию
• По результатам опытной эксплуатации перевод системы в
промышленную эксплуатацию
83
• Поддержка пользователей
• Проведение обучающих лекция для пользователей
• Подготовка отчетов о работе системы
Сопровождение
• Анализ ошибок и их устранение
• Подготовка отчетов по модификациям и изменениям
• Обновление функционирующих систем
На первоначальном этапе после проведения анализа деятельности
организации, необходимо поставить цели и задачи автоматизации и разработать
план проекта. После документального оформления начинается непосредственно
сам процесс разработки. Создается база данных, отчетные формы, пишется
программный код по сбору, обработке и хранению информации, создаются
процедуры фильтрации. После разработки системы, проходит этап тестирования.
По завершению тестирования готовится план эксплуатации и документация для
внедрения, а так же различная пользовательская документация. Процесс будет
происходить следующим образом. Так как в организации уже существует ЛВС и
стабильно функционирует, в ее наладке нет необходимости. Первоначально
устанавливается серверная часть системы учета продаж, далее на рабочие места
проходит установка и настройка клиентских приложений системы учета продаж и
СУБД. Тестируется работоспособность, проводится демонстрация работы системы
для руководства и персонала. Последней стадией будет проведение семинаров для
сотрудников компании. Необходимо связать всех сотрудников, отвечающих за
обработку документов в единую информационную сеть. Для этого клиентские
приложения будут устанавливаться в четкой последовательности по определенным
отделам
За эксплуатацию готовой системы, будет отвечать оператор. В его задачу
будет входить:
1. Разработка плана эксплуатации и определения набора стандартов
эксплуатации.
2. Получение и документирование сведений о возникающих проблемах, их
решение и контроль за возникновением, обеспечение обратной связи с
пользователями.
84
3. Тестирование системе в эксплуатационной среде, кооперация со службой
сопровождения для устранения возникших проблем и модернизации системы.
4. Поддержка и консультация пользователей.
В соответствии с выбранной моделью основными этапами разработки будут
являться:
Формирование требований
Проектирование
Реализация
Тестирование
Ввод в действие
Эксплуатация и сопровождение.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Проект создания информационной системы включает в себя много деталей,
которые могут негативно отразиться на его реализации.
Чтобы таких ситуаций не случалось, на ранних этапах организуется работа
по выявлению возможных рисков для проекта и разрабатываются меры либо по
минимизации негативных последствий рисков, либо их полного предотвращение.
В данное время есть 3 стратегии управления рисками:
• Избежание рисков – проект переделывается таким способом, чтобы
избежать возникновения возможных рисков;
• Передача рисков – проект переделывается таким способом, чтобы
третья сторона (заказчик, банк и т.д) взяла на себя возможные риски
• Принятие рисков – разработчики проекта признают, что риски – это
обязательная часть проекта, и внимательно наблюдают за тем, не появляются ли
факторы, сигнализирующие о появлении риска, из-за этого проводится постоянная
реорганизация плана действий, если эти факторы появятся и негативно скажутся на
проекте.
85
Риски могут быть 2 типов – обратные и прямые. Зачастую на первый тип
можно повлиять проектной командой, и этого нельзя сделать, если появляются
риски второго типа.
Все риски можно разделить на несколько основных видов:
Риски ресурсные:
• Компания (имела ли фирмы ранее проекты такого масштаба, есть ли
какой-то процесс создания ПО и т.п.);
• Оплата (полноценно ли финансирование проекта, указана ли цена
проекта или она пока находится в обсуждении, корректно ли проводилась оценка
затрат и т.п.);
• Персонал (хватает ли сотрудников для реализации проекта, имеют ли
они требуемые навыки и опыт работы, связывала ли их когда-либо похожая
деятельность и т.п.);
• Длительность (актуален ли план проекта, как критична дата окончания
проекта и т.п.);
• Бизнес (что будет, если конкурент займет место первым, насколько
больше прибыль от реализации проекта, чем затраты на него, что будет, если
основные поставщики перестанут выполнять свои обязательства и т.п.);
Риски технические:
• Зона покрытия проекта (могут ли меняться параметры корректного
окончания проекта, хорошо ли понятны требования, фиксирована ли область
действия или она может расширяться в дальнейшем и т.п.);
• Методики (насколько изучена применяемая технология и когда она
была создана, есть ли странные, инновационные технические требования, с
которыми команда проекта еще никогда раньше не встречалась и т.п.);
• Другие зависимости (связан ли проект с другими идущими
разработками, зависит ли успех проекта от сторонних компаний, технологий или
продуктов и т.п.).
В данном проекте можно выделить следующие основные риски на каждом
этапе жизненного цикла (таблица 2.15).
Таблица 2.14
Основные риски на этапах жизненного цикла информационной системы
86
Этап
Риск
Мероприятия
Заказ
Несоответствие
выделенного бюджета
масштабу проекта
Переговоры по увеличению бюджета
или отказ от участия в проекте
Заказ
Неформализуемая задача
(невозможно
автоматизировать те или
иные бизнес-процессы или
стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть область действия
проекта с целью выделения
отдельных задач, поддающихся
автоматизации.
Провести детальный анализ бизнес-
процессов и предложить комплекс
мероприятий по их реорганизации.
Проектирование
- неправильное
определение рамок и
масштабов проекта;
- проектирование
ошибочных функций и
интерфейсов будущей
системы;
- выбор неправильных
технологий и методов
решения поставленных
задач;
- несоблюдение требований
заказчика при
проектирование будущей
системы или постоянное
изменение требований.
- обеспечение стабильности границ
проекта, определенных на начальном
этапе, вплоть до окончания проекта;
- качественное планирование работ;
- своевременная идентификация
проектных рисков и разработка
рекомендаций по снижению рисков;
- обеспечение проекта
необходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям
Разработка
Недостаточно ресурсов для
выполнения комплексного
и нагрузочного
тестирования Недостаточно
опыта у персонала
заказчика, который будет
эксплуатировать систему
Заключить договор со
специализированной организацией
на выполнение ею этих работ.
Предоставить заказчику услуги
собственного специалиста для
первоначального сопровождения
системы и постепенного обучения
персонала заказчика.
Продолжение Таблицы 2.15
Этап
Риск
Мероприятия
Внедрение
- увеличение нагрузки на
персонал;
- несогласованность
действий персонала
исполнителя и сотрудников
предметных областей
- проведение обучения персонала
заказчика работы с системой;
- составление плана внедрения ИС
Также в процессе использования и сопровождения созданной ИС возникают: