48
3 Проектная часть
3.1 Разработка проекта автоматизации
3.1.1 Этапы жизненного цикла проекта автоматизации
Методология проектирования ИС включает в себя описание
процесса создания и сопровождения систем в виде жизненного цикла (ЖЦ)
ИС, отождествляя его с некоторой последовательностью стадий и
исполняемых на них процессов. Для каждой стадии выявляется состав и
последовательность производимых работ, итоговые результаты, методы и
средства, нужные для реализации работ, ответственность и роль
участников и т.д. Подобное формальное описание ЖЦ ИС дает
возможность спланировать и подготовить процесс совместной разработки
и поддерживать управление этим процессом.
Жизненный цикл (ЖЦ) ИС представляется, как ряд событий,
случающихся с системой с момента ее внедрения и до окончания
использования.
Модель ЖЦ отражает различные состояния системы, от момента
возникновения необходимости в данной ИС и до момента ее
окончательного вывода из эксплуатации. Модель жизненного цикла
представлена некой структурой, которая содержит процессы, действия и
задачи, реализуемые в ходе создания, работы и сопровождения ПО в
течение всей жизни системы, от выявления требований до окончания ее
использования.
Сегодня известны и применимы следующие модели жизненного
цикла:
• Каскадная модель включает в себя последовательную
реализацию всех этапов проекта в заранее определенном порядке. Начало
49
следующего этапа говорит о полном завершении работ на предыдущем
этапе.
• Поэтапная модель с периодичным контролем. Создание ИС
реализовано в виде итераций с циклами обратной связи между этапами.
Межэтапные проверки позволяют учесть реально существующее
взаимовлияние итогов разработки на различных этапах; ЖЦ каждого из
этапов продлевается на весь срок разработки.
• Спиральная модель. На любом витке спирали выполняется
генерация очередной версии продукта, корректируются требования
проекта, выражается его качество и планируются работы уже следующего
витка. Особое внимание при этом обращается на начальные этапы
разработки - анализ и проектирование, где возможность создания тех или
иных технических решений обосновывается и проверяется благодаря
построению прототипов.
Каскадный подход отлично зарекомендовал себя в процессе создания
относительно простых ИС, когда в самом начале разработки можно с
большой точностью и полнотой составить все требования к системе.
Главным недостатком такого подхода является то, что основной процесс
разработки системы не может полностью уложится в такие жесткие рамки,
постоянно есть потребность в возврате к уже завершенным этапам для
уточнения или изменения ранее принятых решений. В итоге реальный
процесс разработки ИС становится соответствующим поэтапной модели с
периодичным контролем.
Для разработки интернет-магазина выбираем каскадную модель
жизненного цикла.
Все стадии создания системы предусматривают выполнение
некоторого объема работ, представляемых в виде процессов ЖЦ. Процесс
выражается как совокупность объединенных действий, изменяющих
входные данные в выходные. Описание любого процесса состоит из
перечня решаемых задач, исходных данных и итоговых результатов.
50
Есть целый ряд стандартов, определяющих ЖЦ ПО, а в отдельных
случаях и процессы разработки.
Среди самых известных стандартов выделяют следующие:
• ГОСТ 34.601-90 - распространяется на АИС и указывает в себе
стадии и этапы их создания. Также в нем имеется описание содержания
работ на всех этапах. Стадии и этапы работы, отраженные в стандарте,
зачастую соответствуют каскадной модели жизненного цикла.
• ГОСТ Р 12207-2010 - стандарт на процессы и реализацию
жизненного цикла. Применяется ко всем видам заказного ПО. Стандарт не
имеет описания стадий, фаз и этапов.
• Custom Development Method по созданию прикладных ИС -
технологический материал, углублённый до уровня заготовок проектных
документов, которые рассчитаны на применение в проектах совместно с
Oracle. Используется CDM для типовой модели ЖЦ (имеются все
работы/задачи и этапы), а также для случаев "быстрой разработки" (Fast
Track) или "облегченного подхода", которые будут оптимальны в малых
проектах.
• Rational Unified Process (RUP) включает в себя итеративную
модель разработки, имеющую четыре фазы: старт, анализ, создание и
использование. Все эти фазы могут быть разделены на этапы (итерации),
по итогу которых имеется версия для внутреннего или внешнего
использования. Реализация четырех основных фазы считается циклом
разработки, и любой такой цикл завершается созданием версии системы. В
случае, если работа над проектом не прекращается и после этого,
полученный продукт продолжает оптимизироваться и снова проходит те
же фазы. Суть реализации в рамках RUP - это разработка и сопровождение
моделей на базе UML.
51
• Microsoft Solution Framework (MSF) похож на RUP, так же
имеет четыре фазы: исследование, построение, создание, стабилизация,
является итерационным, включает в себя применение объектно-
ориентированного моделирования. MSF в отличии от RUP в сильнее
ориентирован на создание бизнес-приложений.
• Extreme Programming (XP). Экстремальное программирование
(самая молодая среди остальных методологий) было реализовано в 1996
году. В основе методологии лежит командная работа, четкая
коммуникация между исполнителем и заказчиком в течение всего срока
проекта, а сама разработка реализуется методом последовательной
доработки прототипов.
• Стандарт ISO/IEC серии 15288.
При выборе стандарта основным определяющим фактором является
более полное и подробное описание работ на стадиях и этапах разработки
АС(автоматизируемых систем). Стандарт ISO/IEC 12207 не содержит
подробное описание работ на разных стадиях и этапах разработки АС.
Стандарт CDM рассчитан на использование в проектах с применением
Oracle технологий, который в данном проекте не используются. Стандарт
MSF, как было ранее сказано, в большей степени ориентирован на
разработку бизнес-приложений. Стандарт XP ориентирован на командную
работу. В данном проекте будет использоваться ГОСТ 34.601-90, так как
он содержит описание работ на каждом этапе разработки АС.
Стадии создания ИС.
1. Формирование требований к системе,
2. Разработка концепции,
3. Техническое задание,
4. Технический проект,
5. Оформление документации,
6. Внедрение.
52
На этапе “Формирование требований к системе”, производится
следующие работы: обследование объекта, формирование требований
пользователя, обоснование необходимости разработки системы. На данном
этапе задействованы следующее участники: IT-менеджер, начальник
отдела по работе с клиентами. После выполнения всех работ формируется
отчет о проделанных работах - характеристика объекта автоматизации,
описание требований к системе, определение затрат на разработку,
введение в эксплуатацию и сопровождение, ожидаемый эффект от системы
и условия создания и эксплуатации системы.
После выполнения этапа “Формирования требований к системе”
разрабатываются варианты концепции. Производят разработку
альтернативных вариантов концепции и планов реализации, оценку
необходимых ресурсов на реализацию ИС и дальнейшее
функционирование, оценка преимуществ и недостатков каждого варианта,
сопоставление требований пользователя и характеристик предлагаемой
системы. На этапе “Разработка концепции” участвует IT-менеджер. После
выполнения данных работ выбирается один из подходящих вариантов
концепции удовлетворяющий всем требованиям.
После этапа “Разработка концепции” разрабатывается ТЗ
(техническое задание) проекта автоматизации. После разработки и
оформления ТЗ, необходимо его согласовать и утвердить. Участники на
данном этапе работ: IT-менеджер, начальник отдела по работе с
клиентами. В результате данный пункт определяет: функции ИС, функции
подсистем, состав комплекса задач и отдельных задач, концепция
информационной базы, функции систем управления базой данных, а также
функции и параметры программных средств.
Следующим этапом после разработки и утверждения ТЗ идет
разработка проектного решения. IT-менеджер, совместно с
53
программистом, разрабатывают физическую и логическую модель БД,
определяют организацию базы данных. По завершению этапа
“Технический проект” IT-менеджером совместно с программистом
производится оформления рабочей документации, включающие в себя:
технические требования, программные требования, руководство
пользователя.
После выполнения всех работ и оформления рабочей документации
остается этап внедрения разрабатываемого проекта. На этапе внедрения
происходит: подготовка объекта автоматизации, обучение персонала,
производятся строительно-монтажные работы, пусконаладочные работы,
проведение предварительных испытаний, проведение опытной
эксплуатации и проведение приемочных испытаний. Участники данного
этапа: IT-менеджер, системный администратор, начальник отдела работы с
клиентами.. После чего анализируются испытания ИС, проверка на
соответствие ТЗ, устраняются неполадки и подписываются необходимые
акты.
На этапе эксплуатации системы производится ее эксплуатация.
Работы, ожидаемые на этапе эксплуатации, можно разделить на две
группы: плановые и неплановые.
К плановым работам будут относятся такие работы, как:
инсталляция программного обеспечения;
базовая настройка и проверка работоспособности компонентов
устанавливаемой системы;
устранение недостатков в конфигурации системы;
проверка надежности работы системы;
окончательная донастройка.
Данные работы будут проводиться той же группой, что и на ранних
этапах. В состав этой группы входят сотрудники технического отдела —
технические специалисты и системные администраторы, сотрудники ИТ
отдела.
54
Для разрабатываемого проекта наиболее подойдет каскадная модель
для разработки приложения из-за возможности контроля промежуточных
фаз.
Далее произведем выбор стратегии внедрения разработанной
системы. В настоящий момент выделяется четыре стратегии внедрения
информационной системы:
Параллельная стратегия - для случая, когда старую
работающую систему необходимо заменить новой;
Скачок – эта стратегия подразумевает резкий переход от одной
системы автоматизации к другой;
Опытная эксплуатация "пилотного проекта - это тактика
"скачка", но применяемая к ограниченному числу изделий, наиболее
успешна в малом участке деятельности;
Узкое место - при внедрении "узкого места" план внедрения
выполняется только для "узкого места" и для людей, работающих в нем.
Исходя из описания и условий деятельности компании, а также
особенностей разрабатываемой информационной системы, в качестве
стратегии внедрения была выбрана стратегия Опытная эксплуатация
пилотного проекта, так как в этом случае внедрение системы произойдет в
наименьшими потерями для компании.
3.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Проект создания интернет-магазина, как и все остальные проекты по
созданию ПО, включает множество неопределенных моментов, которые
могут повлечь за собой риски срыва реализации проекта.
55
Управление рисками состоит в их раннем выявлении и принятии
мер, которые позволят либо 100% предотвратить их возникновение, либо
значительно уменьшат последствия.
Сегодня существует три общепринятых стратегии управления
рисками:
• Избегание рисков – проект строится так, чтобы исключить
возможность появления любого риска;
• Делегирование рисков – проект строится так, чтобы передать
все риски третьей стороне (инвесторам, банкам, заказчикам и т.п.);
• Принятие рисков – риски считаются неизбежной
составляющей проекта, реализуется постоянный мониторинг симптомов их
проявления, часто дорабатывается план действий в случае возникновения
рисков.
Модно рассмотреть две базовые категории рисков – прямые и
косвенные. На прямые риски проектная команда еще как-то можно
повлиять, а вот косвенные риски нельзя проконтролировать в принципе.
Риски делят на 2 основных вида:
1) Ресурсные риски:
• Организация (делала ли компания прежде проекты
аналогичной сложности, есть ли формальный процесс создания ПО и т.п.);
• Финансирование (обеспечено ли на 100% финансирование
проекта, утверждена ли стоимость проекта или она все еще предмет для
обсуждений, точно ли проведена оценка затрат и т.п.);
• Персонал (хватает ли людей для выполнения проекта, имеют
ли они нужные навыки и опыт, случалось ли им раньше работать вместе и
т.п.);
• Время (актуален ли план проекта, как критична установленная
дата завершения проекта и т.п.);
• Бизнес (что будет, если конкурент выйдет на рынок быстрее,
выгода, полученная от осуществления проекта больше, чем затраты на
56
него, что случится, если ключевые поставщики в силах будут выполнить
свои обязательства и т.п.);
2) Технические риски:
• Область действия проекта (могут ли меняться критерии
правильного завершения проекта, требования понятны и стабильны,
область действия четко фиксирована или будет расширяться в будущем и
т.п.);
• Технологии (применялась ли используемая технология раньше
или она только что разработана, есть ли необычные или инновационные
технические решения, с которыми проектная команда раньше не могла
сталкиваться и т.п.);
• Внешние зависимости (зависит ли проект от выполнения
других проектов, зависит ли успех проекта от сторонних продуктов или
поставщиков и т.п.).
В данном проекте можно выделить следующие основные риски на
каждом этапе жизненного цикла (таблица 8).
Таблица 8
Основные риски на этапах жизненного цикла
информационной системы
Этап
Риск
Мероприятия
Проектирован
ие
- неправильное определение
рамок и масштабов проекта;
- проектирование ошибочных
функций и интерфейсов
будущей системы;
- выбор неправильных
технологий и методов
решения поставленных
задач;
- несоблюдение требований
заказчика при
проектирование будущей
системы или постоянное
изменение требований.
- обеспечение стабильности
границ проекта,
определенных на начальном
этапе, вплоть до окончания
проекта;
- качественное планирование
работ;
- своевременная
идентификация проектных
рисков и разработка
рекомендаций по снижению
рисков;
- обеспечение проекта
необходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям
57
Разработка
Недостаточно ресурсов для
выполнения комплексного и
нагрузочного тестирования
Заключить договор со
специализированной
организацией на выполнение
ею этих работ.
Недостаточно опыта у
персонала заказчика,
который будет
эксплуатировать систему
Предоставить заказчику
услуги собственного
специалиста для
первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
Внедрение
- увеличение нагрузки на
персонал;
- несогласованность
действий персонала
исполнителя и сотрудников
предметных областей
- проведение обучения
персонала заказчика работы с
системой;
- составление плана
внедрения ИС
Кроме того, в процессе эксплуатации и сопровождения
разработанной ИС могут возникнуть:
технические риски;
риски персонала.
Причинами технических рисков становятся:
• Использование вредоносных программ (логические бомбы,
вирусы, трояны, черви, шифровальщики), активированные в корыстных
целях внутри найденных ошибок (дыр) в ПО,
• Перехват данных по сетям связи, воровство данных;
• Неправильная эксплуатация оборудования;
• Проблемы в работе третьего лица (к примеру, провайдера
Интернет услуг), что влечет за собой недоступность передачи отчетов из
филиалов и контроля работы филиалов;
• Расхождение функциональных возможностей системы
текущим бизнес-процессам в комплекс задач ввиду проведенных
реорганизационных изменений.
Минимизировать данные обстоятельства можно, соблюдая
некоторые моменты: