62
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл информационной системы — период времени, который
начинается с момента принятия решения о необходимости создания
информационной системы и заканчивается в момент ее полного изъятия из
эксплуатации.
Существуют следующие стандарты проектирования информационных систем:
ГОСТ 34.601-90;
ISO/IEC 12207:1995 (российский аналог — ГОСТ Р ИСО/МЭК 12207-99);
Custom Development Method (методика Oracle);
Rational Unified Process (RUP);
Microsoft Solutions Framework (MSF).
Экстремальное программирование;
Стандарт ISO/IEC 12207.
Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование,
разработка, стабилизация, предполагает использование объектно-ориентированного
моделирования;
Экстремальное программирование (англ. Extreme Programming, XP). В основе
методологии командная работа, эффективная коммуникация между заказчиком и
исполнителем в течение всего проекта по разработке ИС. Разработка ведется с
использованием последовательно дорабатываемых прототипов.
Стандарт ISO/IEC 12207 задает полный набор процессов (более 40), охватывающий
все возможные виды работ и задач, связанных с построением программного
средства, начиная с анализа предметной области и заканчивая изготовлением
конечного продукта. Данный стандарт содержит основные и вспомогательные
процессы.
В зависимости от проекта процессы, действия и задачи стандарта выбираются,
упорядочиваются и включаются в модель ЖЦ. При применении они могут
перекрывать, прерывать друг друга, выполняться итерационно или рекурсивно. Это
63
определяет "динамический" характер стандарта и позволяет реализовать с его
помощью произвольную модель ЖЦ .
Стандарт XP больше рассчитан на команду. Поэтому в данном проекте используется
ISO/IEC 12207, поскольку именно у него есть описание работы на каждом этапе
разработки АС.
Из данного стандарта можно выбрать только те процессы, которые более всего
подходят для реализации конкретной ИС. Обязательными являются основные
процессы, которые присутствуют во всех известных моделях ЖЦ. В зависимости от
целей и задач предметной области они могут быть пополнены дополнительными
(документирование, обеспечение качества, верификация и валидация и т.п.) и
организационными (планирование, управление и др.) процессами этого стандарта.
Разработчик принимает решение о включении в новую создаваемую модель ЖЦ
процесса обеспечения качества компонентов и системы управления проектом или
определения набора проверочных (верификационных) процедур для обеспечения
правильности продукта и соответствия его заданным требованиям.
На предпроектной стадии необходимо провести системный анализ, включающий
анализ функционирования и выявление недостатков существующей технологии .На
основе выявленных недостатков формулируется потребность в совершенствовании
системы, создается технико-экономическое обоснование проекта (ТЭО),
формулируются технические условия и требования к ИС. Результаты должны быть
оформлены в виде ТЗ (технического задания). Первый этап выполняется бизнес-
аналитиком отдела, с привлечением сотрудников. Входную информацию бизнес-
аналитик получает из интервью с сотрудниками, характеризующих существующие
бизнес-процессы.
Следующий этап – проектирование ИС – включает в себя разработку в соответствии со
сформулированными требованиями состава автоматизируемых функций
(функциональная архитектура), состава обеспечивающих подсистем (системная
архитектура), оформление технического проекта ИС. Входной информацией для
проектирования является ТЗ. На этом этапе определяется состав программных
подсистем и компонентов оборудования, составляются спецификации требований к
компонентам ПО, определяется состав компонентов ПО (в том числе повторно
используемых компонентов), интерфейсы с БД, структуры хранения данных,
алгоритмы обработки информации, спецификации интерфейсов с другими системами
автоматизации, требования к тестам. Данный этап является очень ответственным с
точки зрения качества всей последующей разработки.
64
На этапе реализации выполняется физическое проектирование, программирование,
наполнение баз данных, тестирование, разработка инструкций для персонала.
Тестирование ИС. На этом этапе оценивается система в целом на соответствие
требованиям ТЗ.
Внедрение системы необходимо проводить в три этапа:
подготовка объекта к внедрению;
опытное внедрение;
сдача проекта в промышленную эксплуатацию.
На этапе подготовки объекта к внедрению планируется провести следующие работы:
закупить и установить сервер системы и серверное ПО;
развернуть на сервере базу данных;
установить клиентское ПО на все компьютеры АРМ системы;
сконфигурировать взаимодействие АРМ системы с сервером базы данных;
ввести учетные записи и настроить им права доступа;
заполнить справочники системы реальными данными;
обеспечить пользователей эксплуатационной документацией;
обучить персонал работе с системой.
В процессе внедрения системы участвуют: разработчики системы (проектировщик,
программист), системный администратор и будущие пользователи системы.
Системный администратор должен обеспечить место для установки нового сервера;
подключение к локальной сети для сервера и АРМ пользователей системы; доступ к
компьютерам, необходимым для развертывания системы, с правами
администратора. Проектировщик системы проводит обучение пользователей,
конфигурирует систему, заполняет справочники, проверяет правильность
взаимодействия всех подсистем. Программист оперативно устраняет возникающие
при развертывании системы неполадки.
Опытная эксплуатация системы должна проводиться не менее 3 месяцев. В случае
обнаружения ошибок на этапе опытной эксплуатации, осуществляется поиск причин и
устранение ошибок, внесение коррективов в программу, в технологию обработки
данных. После устранения ошибок подписывается «Акт о проведении опытной
эксплуатации», который служит началом перехода к третьему этапу – сдаче системы в
промышленную эксплуатацию.
65
На этапе эксплуатации производятся следующие работы:
- периодическая актуализация справочников системы (осуществляется ответственным
за справочник лицом);
- периодическое архивирование информационной базы системы на CD-носителях
(администратор системы);
- локализация проблем и устранение причин их возникновения (программист);
- модификация ПО (бизнес-аналитик, программист);
- подготовка предложений по совершенствованию системы (пользователи системы);
- развитие и модернизация системы (бизнес-аналитик, программист).
Рассмотрим существующие модели жизненного цикла.
Каскадная модель предполагает последовательное выполнение всех обозначенных
этапов в строго порядке. Переход на следующий этап показывает полностью
выполненные работы на предыдущих.
Достоинства:
На каждом этапе формируется законченный набор проектной документации,
отвечающий критериям полноты и согласованности. На заключительных этапах также
разрабатывается пользовательская документация, охватывающая все
предусмотренные стандартами виды обеспечения информационной системы
(организационное, методическое, информационное, программное, аппаратное).
Выполняемые в логичной последовательности этапы работ позволяют планировать
сроки завершения и соответствующие затраты.
Несмотря на все свои достоинства, каскадная модель имеет ряд недостатков,
ограничивающих ее применение при разработке информационных систем. Причем
эти недостатки делают ее либо полностью неприменимой, либо приводят к
увеличению сроков разработки и стоимости проекта. В настоящее время многие
неудачи программных проектов объясняются именно последовательным процессом
разработки.
Поэтапная модель с промежуточным контролем. Разработка ИС ведется итерациями
с циклами обратной связи между этапами. Межэтапные корректировки позволяют
учитывать реально существующее взаимовлияние результатов разработки на
66
различных этапах; время жизни каждого из этапов растягивается на весь период
разработки.
Достоинство: межэтапные корректировки обеспечивают меньшую трудоемкость по
сравнению с каскадной моделью;
Недостатки: время жизни каждого из этапов растягивается на весь период
разработки.
Спиральная модель. На каждом цикле выполняется создание очередной версии
продукта, уточняются требования проекта, определяется его качество, планируются
работы следующего цикла.
Особое внимание всегда уделяется начальным этапам разработки – проектированию
и анализу, где все технические решения проверяются и обосновываются посредством
разработки прототипов.
Стандартная каскадная модель, несмотря на частные негативные отзывы за
последнее время, исправно помогала специалистам по программному инжинирингу
много лет. Понимание ее сильных и слабых сторон только улучшает оценочный
анализ других, чаще более эффективных моделей ЖЦ, которые также основаны на
данной модели.
Сама каскадная модель имеет множество преимуществ, но только при условии
использования ее в проекте, приемлемом для нее. Ниже представлены ее
преимущества:
• Модель хорошо знакома потребителям, не имеющим никакого отношения к
созданию и эксплуатации программ, а также конечным пользователям (часто
используется другими компаниями для отслеживания проектов, которые не связана с
разработкой ПО);
• Она лучше справляется с трудностями и отлично срабатывает в тех проектах,
где все достаточно понятно, но трудноразрешимо;
• Она очень доступна для понимания, т.к. преследует простую цель –
выполнение необходимых действий;
• Она проста и удобно в использовании, т.к. процесс разработки идет поэтапно.
Но в случае, если каскадная модель используется в проекте, не предназначенном для
нее, проявляются следующие ее недостатки:
67
• Основа модели – линейная последовательная структура, и в результате
попытки вернуться назад на одну-две фазы для исправления проблемы или
недостатка теряется много времени, увеличиваются затраты и срывается график
работы;
• модель не может предотвращать итерацию между фазами, которые очень
часто встречаются при создании ПО, поскольку сама модель строиться согласно
стандартному циклу аппаратного инжиниринга;
• модель не показывает главное свойство разработки ПО, которое направлено
на решение задачи. Отдельные фазы связаны определенными действиями, что часто
отличается от привычной работы коллектива или персонала;
• модель создает ошибочное впечатление о работе с проектом. Указание, что
«45% выполнено» обычно не имеет какого-то смысла и не служит показателем для
менеджера проектов.
Исходя из недостатков каскадной модели, ее применение нужно ограничивать
ситуациями, в которых все требования для их разработки очень точны и понятны.
Каскадная модель хороша в циклах разработки программного продукта, где
используется фиксированное определение продукта и есть понятные технические
методики.
Спиральная модель особое внимание уделяет начальным этапам разработки –
подготовке стратегии, проектированию и анализу, где все применяемые технические
решения проверяются и обосновываются методом создания прототипов. Каждый
виток спирали означает создание компонента или версии ПО. На них можно уточнять
цели и характеристики проекта, его качество, а также определяются работы на
следующем витке. Таким образом, углубляются и конкретизируются детали проекта,
и в результате определяется обоснованный вариант, который и реализуется.
Спиральная модель несет в себе преимущества каскадной модели. При этом она
включает в себя анализ рисков, умеет ими управлять, а также содержит процессы
поддержки и менеджмента. Еще в ней заложена разработка ПО при использовании
методов прототипирования или быстрой разработки программ при помощи языков
программирования и средств разработки 4-го поколения и выше.
Особые свойства спиральной модели – отказ от закрепления требований и установки
приоритетов пользовательским требованиям; создание последовательных
прототипов, начиная с наиболее высшего; определение и анализ риска на каждом
68
шаге; оценка результата по итогам каждой итерации и планирование проведения
следующей итерации.
Преимуществами спиральной модели можно назвать:
• Быстрая разработка (получение более раннего результата за счет прототипа);
• Постоянное присутствие заказчика с процессе разработки;
• Разбиение большого проекта на малые части;
• Снижение рисков (более предсказуемое поведение системы).
В связи с небольшим объемом проектных работ, а также характером проекта
выберем каскадную модель для описания жизненного цикла. В соответствии с этим в
него будут входить следующие этапы:
Формирование требований
Проектирование
Реализация
Тестирование
Ввод в действие
Эксплуатация и сопровождение
Каскадная модель обладает следующими преимуществами:
не требуется заранее тратить средства, необходимые для разработки
всего проекта (поскольку сначала выполняется разработка и реализация основной
функции или функции из группы высокого риска);
в результате выполнения каждого этапа получается функциональный
продукт;
заказчик располагает возможностью высказаться по поводу каждой
разработанной версии системы;
правило по принципу "разделяй и властвуй" позволяет разбить
возникшую проблему на управляемые части, благодаря чему предотвращается
69
формирование громоздких перечней требований, выдвигаемых перед командой
разработчиков;
существует возможность поддерживать постоянный прогресс в ходе
выполнения проекта.
В качестве стратегии внедрения ИС технической поддержки в АКБ «Лесбанк» (ПАО).
был выбран «Пилотный проект».
Пилотный проект – это первый этап внедрения, позволяющий убедиться в
применимости и эффективности предлагаемой системы до eѐ окончательного
внедрения, обучить сотрудников компании работе с системой, а также определить и
спланировать организационные и технические мероприятия на этапе
промышленного внедрения. Пилотный проект позволяет уменьшить затраты и
ускорить полномасштабное внедрение.
Данная стратегия внедрения информационной системы была выбрана по причинам
минимальных потерь функциональности старой системы до внедрения новой. В
результате реализации пилотного проекта есть возможность оценить
функциональность новой системы до ее полноценного внедрения, скорректировав
имеющиеся недостатки. Такой подход снижает риск и наиболее надежен.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Данный раздел описывает риски, которые могут возникнуть на этапах ЖЦ задачи
технической поддержки для АКБ «Лесбанк» (ПАО).. Риском является возможность
появления обстоятельств, обусловливающих неуверенность или невозможность
получения ожидаемых результатов от реализации поставленной цели, нанесение
материального ущерба, опасность валютных потерь и др. Существуют следующие
типы рисков:
Проектный тип рисков. В него включены риски, которые связаны с ошибками в
бюджете; в графике работ; с проблемами персонала организации; риски различных
изменений в текущем законодательстве.
Технический тип рисков. К нему относят риски, связанные с проблемами реализации
технических решений и человеческим фактором, а именно риски, связанные с
неспособностью специалистов выполнить необходимую задачу.
70
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с финансовой
поддержкой задачи учета, или, другими словами, риски сокращения бюджета,
приводящие не только к сокращению проекта и его задач, но и к его полному провалу
в случае не достижения основной цели; риск потери интереса к задаче ведения и
учета внутренних заказов оборудования со стороны конечных пользователей, риски
при оценке рынка данного вида учета. Данный тип рисков невозможно исключить, но
его можно минимизировать.
Чтобы уменьшить величину данных типов рисков необходимо иметь достаточно
компетентных и квалифицированных сотрудников, имеющих большой опыт работы в
соответствующей области и при этом взаимозаменяемых на сотрудников, не менее
соответствующих данным характеристикам (таблица 2.1).
Таблица 2.1
Характеристики дефектов программного продукта
Этапы возникновения дефектов и ошибок
Типы первичных
дефектов и ошибок
программного средства
и документации
Формирование требований
Разработка требований к
ПО
Дефекты исходных
требований заказчика
Проектирование
Планирование работ
Дефекты,
обусловленные
реальной сложностью
проекта
Проектирование
архитектуры системы
Ошибки планирования и
системного
проектирования
программного средства
Детальное
проектирование ПО
Системные и
алгоритмические
дефекты и ошибки
проекта
Реализация
Кодирование ПО
Программные дефекты и
ошибки компонентов и
документов
программного средства
71
Тестирование
Тестирование ПО
Программные и
алгоритмические
ошибки программного
средства и
документации
Ввод в действие
Разработка документации
Дефекты и ошибки
обобщающих
документов
Эксплуатация и
сопровождение
Эксплуатация ПО
Программные дефекты.
На этапе эксплуатации возможны риски, возникающие по причинам:
1) Злоумышленных, активных воздействий заинтересованных лиц. Для защиты от
внешних угроз необходимо применять средства обеспечения защиты программ и
данных (аутентификация пользователей, защита локальной сети при помощи
межсетевых экранов, применение антивирусных программ и пр.).
2) Случайных негативных проявлений внешней среды, дефектов системы или
ошибочных действий пользователей. Основными источниками отказовых ситуаций
могут быть некорректные исходные требования, сбои и отказы в аппаратуре, дефекты
или ошибки в программах и данных функциональных задач, проявляющиеся при их
исполнении в соответствии с назначением. При таких воздействиях внешняя,
функциональная работоспособность систем может разрушаться не полностью, однако
невозможно полноценное выполнение заданных функций и требований к качеству
информации для потребителей.
Для снижения рисков, связанных с дефектами системы, необходимо проводить
тщательное тестирование на контрольных примерах, приближенных к
действительности. Для снижения рисков, связанных с ошибочными действиями
пользователей, необходимо предусмотреть защиту от применения ошибочных
действий по удалению и порче данных.
На стадии доработки могут возникнуть следующие риски:
увеличение нагрузки на персонал;- несогласованность действий
персонала исполнителя и сотрудников предметных областей;
трудности с обучением персонала заказчика из-за нежелания работать с
новой системой;