67
В зависимости от проекта процессы, действия и задачи стандарта
выбираются, упорядочиваются и включаются в модель ЖЦ. При применении они
могут перекрывать, прерывать друг друга, выполняться итерационно или
рекурсивно. Это определяет "динамический" характер стандарта и позволяет
реализовать с его помощью произвольную модель ЖЦ .
ЖЦ является непрерывным процессом, который изначально начинается с
момента выражения решения о необходимости его создания и заканчивается
после факта изъятия из обращения.
Среди самых популярных стандартов часто выделяют такие:
• ГОСТ 34.601-90 – используется в АИС и устанавливает все этапы и
стадии их создания. Также он описывает содержание работ для любого этапа.
Стадии и этапы, закрепленные внутри стандарта, больше всего соответствуют
каскадной модели ЖЦ;
• ISO/IEC 12207 – стандарт, указывающий процессы и организацию
ЖЦ. Может использоваться в любом виде заказного ПО. Стандарт не имеет
описания стадий и этапов;
• Custom Development Metho – технологический материал по
созданию прикладных ИС, детализированный до уровня заготовок проектных
решений, которыми пользуются в проектах с использованием средств Oracle.
Применяется CDM для классической модели ЖЦ (есть все этапы и описанные
задачи), а также в процессе «оперативной разработки» или «облегченного
прохода», которые применяются в рамках малых проектов;
• Rational Unified Process (RUP) – применяет интерактивную модель
разработки, включающую 4 фазы: старт, изучение, создание и внедрение. Каждая
из фаз может делится на этапы, которые в итоге создают версию для внутреннего
или внешнего применения. Завершение всех 4 фаз – это цикл разработки, и по
завершению одного цикла генерируется новая версия системы. Если по факту
проект продолжается, то сам продукт тоже изменяется и проходит вновь эти 4
фазы. Суть работы при использовании RUP – создание и поддержка моделей на
базе UML;
68
• Microsoft Solution Framework (MSF) – аналогичен RUP, тоже состоит
из 4 фаз: изучение, разработка, реализация и проверка, считается итерационным
и включает применение объектно-ориентированных моделей. MSF в отличии от
RUP чаще всего используется для создания бизнес ПО;
• Extreme Programming (XP) – экстремальное программирование
(современная методология, создана в 1996 году). Ее суть составляют командная
работа, постоянная коммуникация с заказчиком в рамках всего проектирования
ИС, создание проекта с использованием последовательно оптимизируемых
прототипов.
Для определения стандарта главным фактором выступает более подробное
и полноценное описание работы на этапах и стадия АС.
Стандарт ISO/IEP 12207 не включает полноценного описания работы на
этапах и стадиях реализации АС.
Стандарт CDM оправдан при работе с проектами, включающими Oracle-
технологий, которые в нашем случае не используются.
Стандарт MSF, как было описано выше, направлен на бизнес-сферу.
Стандарт XP предпочтителен для команды. Поэтому в нашем случае будет
использоваться ГОСТ 34.601-90, т.к. именно он имеет описание работы на любом
этапе создания АС.
Основные стадии создания АС включают в себя:
1) Определение требований к системе;
2) Подготовка концепции;
3) Подготовка ТЗ;
4) Реализация технического проекта;
5) Написание документации;
6) Установка и использование.
В рамках этапа «Выведение требований к системе» реализуется
следующее:
• Изучается сам объект;
• Готовятся требования пользователя;
• Указывается важность разработки.
69
В данном этапе используются такие участники, как: IT-менеджер,
руководитель отдела производства. По факту создания всех задач готовится отчет
о выполненной работе – описывается объект автоматизации, выделяются
требования системе, отражаются расходы на создание, введение в работу и
поддержку, указывается возможный эффект от реализации и отражаются условия
для корректной работы системы.
По факту реализации этапа «Отражение требований к системе» готовятся
виды концепций. Создается ряд доступных концепции и планов реализации,
анализируют ресурсы, требуемые для реализации ИС и ее адекватной работы,
изучают недостатки и преимущества всех методов, сверяют требования
пользователей и показатели всех предлагаемых систем.
В рамках этапа «Подготовка концепции» используется только IT-
менеджер. По факту завершения всех описанных работ определяется самый
удачный из всех приемлемых вариантов, который сможет полностью
удовлетворить всем требованиям.
По факту завершения этапа «Подготовка концепции» выполняется ТЗ
проекта автоматизации. По факту его подготовки нужно его согласовать и
утвердить. В этом этапе принимают участие: IT-менеджер и руководитель отдела
делопроизводства. По факту завершения этот пункт отражает - функции ИС и
подсистем, состав совокупных и персональных задач, концепцию БД, состав
СУБД, параметры и функции программных средств.
По факту утверждения ТЗ реализуется разработка проектного решения. IT-
менеджер и программист готовят физическую и логическую модель БД,
отражают совокупную организацию данных.
По факту окончания этапа «Подготовка технического проекта» IT-
менеджер и программист готовят рабочую документацию, состоящую из:
программных и технических требований, руководства по применению. По итогу
всех работ и написания документации нужно лишь установить систему.
Этап установки состоит из: подготовки исследуемого объекта, тренинг
сотрудников, проведение пуско-наладочных и монтажных работ, реализация
испытаний, первый опытный запуск и приемочные испытания. На данном этапе
70
задействованы: IT-менеджер, сисадмин, руководитель делопроизводства. По
итогу происходит изучение итогов испытаний ИС, проверка соответствия ТЗ,
устранения возможных неполадок и подпись всех актов.
Сейчас все чаще применяют такую следующую модель ЖЦ:
• Каскадная модель включает в себя последовательную реализацию
описанных этапов в порядке очередности. Переход на дальнейший этап отражает
полную готовность на всех предыдущих.
Поэтапная модель с серединным контролем (Рисунок 3.4). Создание ИС
происходит итерациями с циклами обратной связи по каждому этапу.
Межэтапные проверки помогают учесть реально возникающие взаимовлияния
итогов проектировки на различных этапах; время жизни любого из этапов равно
совокупному периоду создания.
Спиральная модель. Каждый цикл реализует создание другой версии
продукта, утверждаются правила проекта, проверяется уровень его качество,
рассматриваются работы будущего цикла.
Большое внимание уделено стартовым этапам разработки – разработке и
изучению, где все технические решения корректируются и доказываются
методом создания прототипов. Стандартная каскадная модель, несмотря на
частные негативные отзывы за последнее время, исправно помогала
специалистам по программному инжинирингу много лет. Понимание ее сильных
и слабых сторон только улучшает оценочный анализ других, чаще более
эффективных моделей ЖЦ, которые также основаны на данной модели.
Сама каскадная модель имеет множество преимуществ, но только при
условии использования ее в проекте, приемлемом для нее. Ниже представлены
ее преимущества[11]:
• Модель хорошо знакома потребителям, не имеющим никакого
отношения к созданию и эксплуатации программ, а также конечным
пользователям (часто используется другими компаниями для отслеживания
проектов, которые не связана с разработкой ПО);
• Она лучше справляется с трудностями и отлично срабатывает в тех
проектах, где все достаточно понятно, но трудноразрешимо;
71
• Она очень доступна для понимания, т.к. преследует простую цель –
выполнение необходимых действий;
• Она проста и удобно в использовании, т.к. процесс разработки идет
поэтапно.
Но в случае, если каскадная модель используется в проекте, не
предназначенном для нее, проявляются следующие ее недостатки:
• Основа модели – линейная последовательная структура, и в
результате попытки вернуться назад на одну-две фазы для исправления
проблемы или недостатка теряется много времени, увеличиваются затраты и
срывается график работы[15];
• модель не может предотвращать итерацию между фазами, которые
очень часто встречаются при создании ПО, поскольку сама модель строиться
согласно стандартному циклу аппаратного инжиниринга;
• модель не показывает главное свойство разработки ПО, которое
направлено на решение задачи. Отдельные фазы связаны определенными
действиями, что часто отличается от привычной работы коллектива или
персонала;
• модель создает ошибочное впечатление о работе с проектом.
Указание, что «45% выполнено» обычно не имеет какого-то смысла и не служит
показателем для специалиста проектов.
Исходя из недостатков каскадной модели, ее применение нужно
ограничивать ситуациями, в которых все требования для их разработки очень
точны и понятны.
Каскадная модель хороша в циклах разработки программного продукта,
где используется фиксированное определение продукта и есть понятные
технические методики[16].
Спиральная модель особое внимание уделяет начальным этапам
разработки – подготовке стратегии, проектированию и анализу, где все
применяемые технические решения проверяются и обосновываются методом
создания прототипов. Каждый виток спирали означает создание компонента или
версии ПО. На них можно уточнять цели и характеристики проекта, его
72
качество, а также определяются работы на следующем витке. Таким образом,
углубляются и конкретизируются детали проекта, и в результате определяется
обоснованный вариант, который и реализуется.
Спиральная модель несет в себе преимущества каскадной модели. При
этом она включает в себя анализ рисков, умеет ими управлять, а также содержит
процессы поддержки и менеджмента. Еще в ней заложена разработка ПО при
использовании методов прототипирования или быстрой разработки программ
при помощи языков программирования и средств разработки 4-го поколения и
выше.
Особые свойства спиральной модели – отказ от закрепления требований и
установки приоритетов пользовательским требованиям; создание
последовательных прототипов, начиная с наиболее высшего; определение и
анализ риска на каждом шаге; оценка результата по итогам каждой итерации и
планирование проведения следующей итерации.
Преимуществами спиральной модели можно назвать[17]:
• Быстрая разработка (получение более раннего результата за счет
прототипа);
• Постоянное присутствие заказчика с процессе разработки;
• Разбиение большого проекта на малые части;
• Снижение рисков (более предсказуемое поведение системы).
В связи с небольшим объемом проектных работ, а также характером
проекта выберем каскадную модель для описания жизненного цикла. В
соответствии с этим в него будут входить следующие этапы:
Формирование требований
Проектирование
Реализация
Тестирование
Ввод в действие
Эксплуатация и сопровождение
Каскадная модель обладает следующими преимуществами:
73
не требуется заранее тратить средства, необходимые для разработки
всего проекта (поскольку сначала выполняется разработка и реализация
основной функции или функции из группы высокого риска);
в результате выполнения каждого этапа получается
функциональный продукт;
заказчик располагает возможностью высказаться по поводу каждой
разработанной версии системы;
правило по принципу "разделяй и властвуй" позволяет разбить
возникшую проблему на управляемые части, благодаря чему предотвращается
формирование громоздких перечней требований, выдвигаемых перед командой
разработчиков;
существует возможность поддерживать постоянный прогресс в ходе
выполнения проекта.
В качестве стратегии внедрения ИС учета заявок в ФКУ «Налог-Сервис»
был выбран «Пилотный проект».
Пилотный проект – это первый этап внедрения, позволяющий убедиться в
применимости и эффективности предлагаемой системы до eѐ окончательного
внедрения, обучить сотрудников компании работе с системой, а также
определить и спланировать организационные и технические мероприятия на
этапе промышленного внедрения. Пилотный проект позволяет уменьшить
затраты и ускорить полномасштабное внедрение.
Данная стратегия внедрения информационной системы была выбрана по
причинам минимальных потерь функциональности старой системы до внедрения
новой. В результате реализации пилотного проекта есть возможность оценить
функциональность новой системы до ее полноценного внедрения,
скорректировав имеющиеся недостатки. Такой подход снижает риск и наиболее
надежен.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Данный раздел описывает риски, которые могут возникнуть на этапах ЖЦ
задачи технической поддержки для ФКУ «Налог-Сервис».. Риском является
74
возможность появления обстоятельств, обусловливающих неуверенность или
невозможность получения ожидаемых результатов от реализации поставленной
цели, нанесение материального ущерба, опасность валютных потерь и др.
Существуют следующие типы рисков[11]:
Проектный тип рисков. В него включены риски, которые связаны с
ошибками в бюджете; в графике работ; с проблемами персонала организации;
риски различных изменений в текущем законодательстве.
Технический тип рисков. К нему относят риски, связанные с проблемами
реализации технических решений и человеческим фактором, а именно риски,
связанные с неспособностью специалистов выполнить необходимую задачу.
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски сокращения
бюджета, приводящие не только к сокращению проекта и его задач, но и к его
полному провалу в случае не достижения основной цели; риск потери интереса к
задаче ведения и учета внутренних заказов оборудования со стороны конечных
пользователей, риски при оценке рынка данного вида учета. Данный тип рисков
невозможно исключить, но его можно минимизировать[24].
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих
большой опыт работы в соответствующей области и при этом взаимозаменяемых
на сотрудников, не менее соответствующих данным характеристикам (таблица
2.1).
Таблица 2.1
Характеристики дефектов программного продукта
Этапы возникновения дефектов и ошибок
Типы первичных
дефектов и ошибок
программного средства
и документации
Формирование требований
Разработка требований к
ПО
Дефекты исходных
требований заказчика
Проектирование
Планирование работ
Дефекты,
обусловленные
реальной сложностью
проекта
Проектирование
Ошибки планирования
75
архитектуры системы
и системного
проектирования
программного средства
Детальное
проектирование ПО
Системные и
алгоритмические
дефекты и ошибки
проекта
Реализация
Кодирование ПО
Программные дефекты
и ошибки компонентов
и документов
программного средства
Тестирование
Тестирование ПО
Программные и
алгоритмические
ошибки программного
средства и
документации
Ввод в действие
Разработка документации
Дефекты и ошибки
обобщающих
документов
Эксплуатация и
сопровождение
Эксплуатация ПО
Программные дефекты.
Процессы изучения и минимизации рисков сопутствуют главным этапам
разработки и поддержания ЖЦ сложных программных средств в рамках
международных стандартов. [6]
При начальной постановке задачи и требований к системе часто
возникают ошибки и неточности, приводящие к полному несоответствию
созданного ПО потребностям отдела. Для уменьшения этого риска нужно
привлечь к реализации задачи самых опытных разработчиков, а также
руководство фирмы.
На этапах создания и внедрения системы можно иметь риск:
• Покидания проекта одного или группы ключевых специалистов.
Тогда разработка системы оказывается под угрозой срыва. Руководству фирмы
важно принять меры для минимизации этих рисков, к примеру, поддерживать
более тесное сотрудничество персонала, манятся важными данными, учитывать
взаимную замену сотрудников.
• Увеличения сроков процесса разработки, следственно, повышения
затрат на разработку. Для минимизации этого риска нужен строгий контроль
76
следования графику разработки. Принятые на разработку ИС отдела
специалисты не могут быть задействованы на прочих проектах и заданиях, их
трудовое время должно быть направлено на разработку ИС.
• Корректив требований по ходу создания проекта, которые нарушают
все сроки и оценки. Для минимизации данного риска важно привлекать
сотрудников отдела на границах всех этапов для нахождения изменений на
ранних стадиях работы над проектом системы.
• Допущения дефектов ПО вследствие ошибок, которые были
сделаны на начальных этапах создания системы.
На этапе эксплуатации допускаются риски, связанные с:
1) Злоумышленными, активными воздействиями заинтересованных лиц.
Чтобы защитится от внешних угроз, нужно использовать средства поддержания
защиты программ и данных (проверка пользователей, безопасность ЛВС
методом установки межсетевых экранов, использование антивирусов);
2) Случайными проявлениями внешней среды, дефектами системы или
неверными действиями пользователей. Главными причинами таких ситуаций
становятся некорректные исходные данные, поломки и отказы аппаратуры,
ошибки и недоработки в программах и задачах, проявляющиеся в процессе их
выполнения в рамках своего назначения. При аналогичных воздействиях
внешняя, функциональная способность систем не разрушается на 100%, но уже
нельзя полностью выполнить заданные функций и требований к качеству данных
для потребителей.
Для минимизации рисков, связанных с ошибками системы, важно
проводить подробное тестирование на предоставленных приближенных к
реальности примерах. Для минимизации рисков, которые связаны с неверными
действиями пользователей, нужно найти защиту от использования ошибочных
действий по порче и удалению данных.
На стадии доработки могут возникнуть следующие риски:
увеличение нагрузки на персонал;- несогласованность действий
персонала исполнителя и сотрудников предметных областей;