45
II ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл информационной системы представляет собой
непрерывный процесс, который начинается в момент принятия решения о
создании информационной системы, и заканчивается в момент полного изъятия
информационной системы из эксплуатации [7].
Для стандартизации и эффективности процесса разработки протекание
жизненного цикла определяют выбором конкретной модели жизненного цикла.
Под моделью жизненного цикла программного обеспечения понимают
структуру, содержащую процессы, действия и задачи, осуществляемые в ходе
разработки, функционирования и сопровождения программного продукта в
течение всей жизни системы, от определения требований до завершения ее
использования [10].
На данный момент известны модели жизненного цикла такие как:
1) Каскадная модель (модель водопада) предполагает, что система будет
спроектирована во всех подробностях и только потом начнется ее реализация,
тестирование и ввод в эксплуатацию. Переход от стадии к стадии этой модели
возможен только после полного завершения работ на текущей стадии. Возврат
на пройденные стадии недопустим.
Преимущества каскадного подхода заключается в том, что после каждого
этапа формируется готовый комплект документов и руководств на следующий
этап, последовательность в работах позволяет определить сроки этапов и их
стоимость
На самом деле, требования к системам могут меняться уже на этапе
разработки, и подобная модель не может быть адаптирована к изменяющимся
условиям, возникшие проблемы могут быть обнаружены слишком поздно,
проект при такой модели редко заканчивается в срок и запланированным
бюджетом, нагрузка на членов проекта различна. Поэтому данная модель
46
применима только в небольших проектах с известными требованиями. На
рисунке 2.1 представлена схема каскадной модели и содержание ее этапов.
Рис. 2.1. Каскадная модель (метод водопада)
2) Эволюционная модель (поэтапная модель с промежуточным
контролем), представленная на рис. 2.2, аналогична каскадной модели, но
отличается от нее итерационным подходом с поэтапным уточнением требований
к системе. Достоинством этой модели является учет требований заказчика, его
участие в проекте, раннее обнаружение проблем, равномерная нагрузка на
разработчиков. Недостаток: большая длительность проекта, запутанность
документации, сложность в планировании. Такая модель подходит лишь для
небольших информационных систем.
Формирование
требований
Проектирование
Реализация
Тестирование
Ввод в
действие
Эксплуатация и
сопровождение
Снятие с
экспуатации
47
Рис. 2.2. Эволюционная модель создания программного обеспечения
3) Спиральная модель (рисунок 2.3). На каждом витке спирали
выполняется создание очередной версии продукта, уточняются требования
проекта, определяется его качество и, планируются работы следующего витка.
Решение о переходе на новый виток выполняется только после окончания и
проверки работ предыдущего. Если проект нецелесообразен, его можно
досрочно прекратить. К достоинствам и недостаткам этой модели можно отнести
все достоинства и недостатки эволюционной модели. Особое достоинство - на
каждом витке создается работоспособная версия продукта. Один виток
непродолжителен по времени (максимально месяц).
Формирование
требований
Проектирование
Реализация
Тестирование
Ввод в
действие
Эксплуатация и
сопровождение
Снятие с
экспуатации
48
Рис. 2.3. Схема спиральной модели жизненного цикла
На практике наибольшее распространение получили:
• каскадная модель в период 1970-1985 гг.;
• спиральная модель после 1986 г.
Поскольку в разработке модуля не предполагается участие большой
группы специалистов, проект мал, а требования известны и неизменны, была
выбрана каскадная модель жизненного цикла программного обеспечения.
Жизненный цикл программного обеспечения, а также процессы
разработки регламентируются рядом стандартов, наиболее известные из которых
[10]:
ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания».
Стандарт используется в основном при исследовании и проектировании
автоматизированных систем, устанавливая стадии и этапы их создания.
Стандарт описывает содержание работ на каждом этапе. Стадии и этапы
соответствуют каскадной модели.
49
ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология.
Системная и программная инженерия. Процессы жизненного цикла
программных средств». Стандарт используется при приобретении систем,
программных продуктов и услуг, при их поставке, разработке, применению по
назначению, а также при сопровождении и прекращении применения
программных продуктов и программных компонентов системы, как в самой
организации, так и вне нее. Стандарт устанавливает общую структуру процессов
жизненного цикла программных средств, не устанавливая конкретные модели
жизненного цикла системы или программных средств, разработки методологии,
методов, моделей или технических приемов.
Custom Development Method - методика компании Oracle,
рассчитанная на использование в проектах с применением Oracle, позволяющая
разрабатывать прикладные информационные системы - технологический
материал, детализированный до уровня заготовок проектных документов.
Применяется методика для классической модели жизненного цикла
(предусмотрены все работы/задачи и этапы), а также для технологий "быстрой
разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае
малых проектов.
Rational Unified Process (RUP) предполагает использование
итеративной модели разработки, включающей четыре фазы: начало,
исследование, построение и внедрение. Каждая фаза может быть разбита на
этапы – итерации, результатом которой является выпуск версия для внутреннего
или внешнего использования. Прохождение четырех основных фаз именуют
циклом разработки, каждый цикл завершается генерацией версии системы, при
этом разработка может быть продолжена далее, образуя новый цикл,
завершаемый более качественной версией системы. Использование стандарта
RUP предполагает создание и сопровождение моделей на базе UML.
Microsoft Solution Framework (MSF) – это аналогичен стандарту
RUP, но отличается использованием объектно-ориентированного
моделирования, большей степенью ориентированности на разработку бизнес-
приложений, названиями фаз: анализ, проектирование, разработка,
стабилизация.
50
Extreme Programming (XP). Данный стандарт применяется при
командной работе, предполагает эффективную коммуникацию между
заказчиком и исполнителем в течение всего проекта по разработке
информационной системы, разрабатывается проект с использованием
последовательно дорабатываемых прототипов.
ГОСТ Р ИСО/МЭК 15288-2005. «Информационная технология.
Системная инженерия. Процессы жизненного цикла систем» - определяет
основы для описания жизненного цикла систем (созданных людьми), детально
структурированные процессы и соответствующую им терминологию, но не
детализирует процессы жизненного цикла в терминах методов и процедур,
необходимых для удовлетворения требований и достижения результатов
процесса [2].
Поскольку в рассматриваемой задаче модуль разрабатывается с
использованием каскадной модели, не предполагается использование продуктов
компании Oracle, разработка прототипов не рассматривается ввиду ускорения
разработки, для разработки модуля был выбран стандарт ГОСТ 34.601-90
«Автоматизированные системы. Стадии создания»
Стадия жизненного цикла представляет собой ограниченную временными
рамками часть жизненного цикла, по завершении которой достигается
определенный важный результат в соответствии с требованиями для данной
стадии жизненного цикла [10].
Для ускорения процесса разработки, ввиду участия в проекте только
дипломника, принимающего решения, а также из-за специфики
рассматриваемого модуля принято решение отказаться от ведения
документации.
Опишем стадии создания разрабатываемого модуля рассматриваемой
задачи, используя стандарт ГОСТ 34.601-90 [1]:
1. Формирование требований к автоматизированной системе.
1.1 Обследование объекта и обоснование необходимости создания АС.
Цель этапа – определить необходимость и целесообразность
разработки посредством изучения области деятельности компании и
имеющихся технологий, а также возможных направлений развития
51
компании в будущем. В результате обследования получены
описанные выше сведения и принято решение о проведении
разработки модуля для рассматриваемой задачи.
1.2 Формирование требований пользователя к АС. Целью этапа
является определение характеристик для удобного и простого
взаимодействия пользователя с модулем.
2. Разработка концепции АС.
2.1 Изучение объекта. На данном этапе изучаются существующие
технологии и решения, удовлетворяющие требованиям пункта 1.2 и
технологиям пункта 1.1.
2.2 Разработка вариантов концепции АС, удовлетворяющего
требованиям пользователя. Целью данного этапа является выбор
лучшего из найденных решений.
3. Эскизный проект. Разработка предварительных проектных решений по
системе и её частям. Цель этапа - установка и проверка
работоспособности, а также изучение механизма работы найденного
решения, содержащего описание необходимых настроек для внедрения
этого решения.
4. Технический проект. Разработка проектных решений по системе и её
частям. Целью этапа является определение схемы работы
дорабатываемого модуля, в наибольшей степени соответствующей
рассматриваемой задаче, пересмотр существующих алгоритмов модуля и
разработка необходимых.
5. Рабочая документация. Разработка или адаптация программ. На данном
этапе на основе определенных на предыдущем этапе схем и алгоритмов
работы модуля, производится изменение имеющегося и разработка
отсутствующего программного кода модуля.
6. Ввод в действие.
6.1 Подготовка объекта автоматизации к вводу АС в действие. На этом
этапе для специалистов рассматриваемого предприятия пишется
инструкция, поясняющая ряд действий для внедрения
разработанного модуля.
52
6.2 Проведение предварительных испытаний. На этапе
предварительных испытаний проводится испытание всех функций
разрабатываемого модуля, выявляются и устраняются
обнаруженные недостатки.
6.3 Проведение опытной эксплуатации. На этапе опытной эксплуатации
проводится испытания работы модуля на компьютере,
имитирующем сервер компании ЗАО «Артур - Фарм». При
обнаружении недостатков, проводится их устранение и
соответственно изменение инструкции.
6.4 Проведение приёмочных испытаний. На данном этапе производится
установка, настройка и испытание разработанного программного
обеспечения на сервере компании сотрудниками IT-отдела
компании. Дальнейшее сопровождение разработанного модуля
осуществляет IT-отдел компании.
Существуют следующие способы приступить к использованию новой
системы:
Параллельная стратегия дает возможность работы одновременно как на
«старой» системе, так и на внедренной. Результаты постоянно сравниваются,
внедренная система адаптируется. Основным недостатком являются
значительные трудозатраты (вследствии дублирования), большие сроки
внедрения.
Скачок (шоковая терапия) предполагает резкий переход организации к
использованию внедряемой системы.
Пилотный проект – это «скачок» в рамках одного производственного
участка. Позволяет произвести переход к внедряемой системе поэтапно.
Узкое место. Автоматизация наиболее «узкого» производственного места
с постепенным расширением области автоматизации.
Поскольку сотрудники ЗАО «Артур – Фарм» не используют сайт
непосредственно для проверки приема платежей, выбрана стратегия «скачок».
53
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Раньше при проектировании простых информационных систем каждое
приложение представляло собой единый, функционально и информационно
независимый блок. Для разработки такого типа приложений эффективным
оказался каскадный способ. Каждый этап завершался после полного выполнения
и документального оформления всех предусмотренных работ.
Основные риски этого подхода – выход за рамки сроков проектирования
бюджета, разработка проекта заново, так как может оказаться, что
спроектированная система полностью неприемлема. Риски заказчика при этом
связаны с неполным достижением целей проекта и не эффективно
израсходованными средствами, а риски исполнителя - с возможностью резкого
превышения фактической себестоимости работ по сравнению с плановой
работой.
Для исключения рисков каскадной модели используется поэтапная модель
с промежуточным контролем. Но данная модель тоже обладает рисками -
возврат на предыдущие этапы удлиняют продолжительность разработки
программного обеспечения.
Необходимость ведения параллельных и подчас принципиально
отличающихся по своему характеру работ приводит к тому, что многократно
возрастает уровень риска проекта.
Спиральная модель ЖЦ была предложена для преодоления
перечисленных проблем. На этапах анализа и проектирования реализуемость
технических решений и степень удовлетворения потребностей заказчика
проверяется путем создания прототипов. Каждый виток спирали соответствует
созданию работоспособного фрагмента или версии системы. На каждом витке
уточняются требования, цели и характеристики проекта, определяется качество
разработки, планируется работы следующего витка спирали. Таким образом,
углубляются и последовательно конкретизируются детали проекта и, в
результате выбирается обоснованный вариант, который удовлетворяет
действительным требованиям заказчика и доводится до реализации.
54
В рассматриваемой задаче требования заказчика понятны и не измены,
каскадная модель устраняет необходимость параллельных и подчас
принципиально отличающихся по своему характеру работ, поэтому в таблице 2.1
приведены общие наиболее характерные риски и методы их минимизации.
Таблица 0.1
Возможные риски проекта и способы их минимизации
Виды рисков
Снижение видов риска
Снижение вероятности
возникновения риска
Риски, связанные с масштабом
проекта
Детальный анализ каждого этапа
работ, взаимодействия
участников, организации работ
Детально проработанная
программа качества,
отработанное управление
конфигурацией проекта,
специальные процедуры
взаимодействия участников
Риски, связанные с
недостаточным опытом в сфере
IT
Проведение обучения
пользователей, включая
руководство, соблюдение
технологий работы
Разработка и утверждение
концепции проекта на возможно
более ранней его стадии
Технические риски проекта
Строгий отбор проектной
команды по квалификационным
критериям. Обучение участников
проекта технологии проектных
работ, инструментальным
средствам
Использование стандартов
предприятия на проектные
работы, разработка стандартов
проекта
Организационные риски проекта
Обучение участников проекта
(курс "управление проектом"),
тренинги команды, как можно
более полная формализация
деятельности
Включение в команду
администратора проекта,
детальное распределение ролей в
проекте
Операционные риски проекта
Многократное тестирование
созданных продуктов,
тщательная экспертиза
документов
Строгое выполнение процедур
программы качества