53
Моделью ЖЦ ИС называется некоторая структура, которая определяет
последовательность осуществления действий, процессов и задач, и которые
должны выполнятся на протяжении всего жизненного цикла ИС, а также
взаимосвязи между этими задачами, процессами и действиями.
В стандарте ISO/IEC 12207 не уделено внимание конкретизации деталей и
методов реализации и выполнения задач и действий, которые входят в процессы
ЖЦ ИС, а лишь представлено описание структуры данных процессов, так как
стандарт является общим не только для любых моделей жизненного цикла, но и
для всех технологий и методологий разработки ПО. Модель же ЖЦ зависит от
специфики ИС и условий, в которых она разрабатывается и функционирует.
Поэтому нет смысла предлагать какие-либо конкретные модели ЖЦ и методы
разработки ИС для общего случая, без привязки к определенной предметной
области. На сегодняшний день самими распространенными являются две
основные модели жизненного цикла:
− каскадная модель;
− итерационная модель;
− спиральная модель.
Каскадная модель является классическим подходом к разработке
различных систем вне зависимости от применения их в прикладных областях.
Для разработки ИС данная модель широко применялась в 70-х - 80-х годах.
Каскадные методы проектирования хорошо описаны в отечественной и
зарубежной литературе разных направлений - стандартах, методических
монографиях, учебниках. Организация работ по каскадной схеме официально
рекомендовалась и широко использовалась в различных отраслях.
Каскадная модель представляет последовательную организацию работ.
При этом главной особенностью данной модели является разбиение всей
разработки любого программного продукта на этапы. Следует отметить, что
переход с одного этапа на следующий происходит только после того, как все
работы будут полностью завершены на предыдущем этапе. Каждый этап при
этом завершается выпуском полного комплекта документации, которой
достаточно для того, чтобы разработка могла быть продолжена сторонней
командой разработчиков.
54
На сегодняшний день можно выделить ряд устойчивых этапов
разработки программного обеспечения, которые практически не зависят от
предметной области:
− анализ требований, которые предоставляет заказчик;
− проектирование системы (разработка алгоритмов, прототипов,
реализация структуры БД);
− разработка системы;
− тестирование и опытная эксплуатация разработанного продукта;
− сдача готового продукта.
Первый этап каскадной модели включает в себя исследование проблемы,
которая должна быть решена, происходит четкое формулирование всех
требований заказчиков. Результатом, который получается на данном этапе,
является техническое задание (далее ТЗ), которое прошло согласование со всеми
заинтересованными сторонами.
На втором этапе происходит разработка проектного решения, которое
будет удовлетворять всем требованиями, определенным в ТЗ. Результатом
второго этапа будет являться проектная документация, которая содержит все
необходимое для реализации проекта.
Третьим этапом является реализация проекта. На данном этапе
осуществляется разработка ПО в соответствии с проектными решениями,
которые получены на предыдущем этапе. Методы, которые применяются для
реализации, не имеют принципиального значения. Результатом выполнения
данного этапа является готовое ПО.
На четвертом этапе происходит проверка разработанного ПО на предмет
соответствия требованиям, которые в свою очередь были определены в ТЗ.
Опытная эксплуатация в данном случае позволит выявить различного рода
скрытые недостатки, которые проявляются только в реальных условиях работы
ИС.
Последним этапом является сдача готового проекта, главной задачей
которого является убеждение заказчика, что все его требования реализованы в
полной мере.
55
Каскадная модель имеет несколько положительных сторон, благодаря
которым она при выполнении различного рода инженерных разработок хорошо
зарекомендовала себя и благодаря чему является широко распространенной.
Рассмотрим основные достоинства использования данной модели:
− на каждом этапе каскадной модели происходит формирование
законченного набора проектной документации, которая отвечает критериям
согласованности и полноты. На последних этапах также происходит разработка
пользовательской документации, которая в свою очередь охватывает все виды
обеспечения ИС, предусмотренные стандартами: методическое,
информационное, организационное, аппаратное и программное;
− этапы работ, которые выполняются в логичной последовательности,
позволяют планировать не только сроки завершения, но и соответствующие
затраты.
Но, несмотря на все эти достоинства, каскадная модель обладает рядом
недостатков, которые ограничивают ее применение при разработке ИС. При
этом данные недостатки делают данную модель либо полностью неприменимой,
либо способствуют увеличению как стоимости проекта, так и сроков разработки.
На сегодняшний день многие неудачи программных проектов объясняются
именно применение последовательного процесса разработки.
Рассмотрим недостатки каскадной модели при ее применении для
разработки ИС:
− огромная задержка в получении результатов при разработке системы.
Этот недостаток проявляется в основном в том, что из-за применения
последовательного подхода к разработке согласование результатов с
заказчиками производится только после завершения очередного этапа работ.
Поэтому может оказаться, что разрабатываемая ИС не соответствует
требованиям пользователей.
− выявление ошибок и недоработок, как правило, происходит не на
текущем этапе работ, а при проведении следующего этапа работ, что напрямую
ведет к необходимости возвращения на предыдущие стадии. Последовательная и
поэтапная работа над проектом может являться следствием того, что ошибки,
которые были допущены на ранних этапах, как правило, обнаруживаются только
56
при работе на следующих стадиях над проектом. Поэтому, после того как были
выявлены ошибки, происходит возвращение проекта на предыдущий этап, с
последующим устранением ошибок и передачи проекта на последующую
стадию. Все это обычно является основной причиной усложнения
взаимоотношений между группами разработчиков, которые выполняют
отдельные этапы работы и тем самым срыва графика работ.
− сложность параллельного введения работ по проекту. Сложность
параллельной работы заключается в необходимости постоянного согласования
участниками проекта его различных частей. Чем сильнее зависят между собой
отдельные части проекта, тем чаще происходит синхронизация данных частей и
тем более сильно зависят группы разработчиков друг от друга. Поэтому
преимущества, которые предоставляет параллелизация работ просто теряются.
− на каждом этапе происходит слишком большая информационная
перенасыщенность. Данная проблема возникает из-за наличия между
различными группами разработчиков сильной зависимости и заключается в том,
что при необходимости внесения изменений в какие-либо одну из частей
проекта существует необходимость оповещения всех разработчиков, которые
могли использовать или использовали в своей работе данную часть. Когда
система включает в себя большое количество взаимосвязанных подсистем, то
синхронизация внутренней документации является огромной самостоятельной
задачей.
− сложность управления проектом. Сложность управления проектом при
применении каскадной модели обуславливается наличием сложных
взаимосвязей между различными частями проекта и строгой
последовательностью стадий разработки.
− ненадежность инвестиций и высокий уровень риска. Чем сложнее
проект, тем намного больше времени необходимо на выполнение каждого из
этапов разработки и тем более сложными являются взаимосвязи между
отдельными частями проекта, количество которых также со временем
увеличивается. Причем результаты работы над проектом можно реально
определить и оценить только на этапе тестирования системы, то есть после
завершения стадий анализа, проектирования и разработки, при этом выполнение
57
данных стадий требует значительного средств и времени. Как уже было сказано,
поздняя оценка проекта создает огромные проблемы при выявлении ошибок на
стадиях анализа и проектирования, поэтому необходим возврат проекта на
предыдущие стадии и повторение всего процесса разработки.
− Рассмотрим итерационную модель ЖЦ. Данная модель является
идеальной, так как только очень простые задачи проходят все этапы без каких-
либо итераций — возвратов на предыдущие шаги технологического процесса.
При разработке больших нетрадиционных систем как из-за допущенных на
предыдущих шагах ошибок и неточностей, так и из-за изменений внешних
требований к условиям эксплуатации системы возникает необходимость в
итерациях на любом этапе жизненного цикла. Использование данной модели при
разработке позволяет вернутся на любой этап и исправить ошибку.
Классическая итерационная модель абсолютизирует возможность
возвратов на предыдущие этапы. Однако это обстоятельство отражает
существенный непреодолимый аспект программных разработок, которые не
опираются на объектно-ориентированное проектирование - стремление заранее
предвидеть все ситуации применения системы и невозможность в подавляющем
большинстве случаев достичь этого.
Все традиционные технологии программирования направлены лишь на то,
чтобы минимизировать возвраты. Но следует отметить, что при возврате всегда
приходится повторять построение того, что уже считалось готовым .
При использовании данной модели с объектно-ориентированными
технологиями, позволяет отказаться от завершенности фаз и этапов, вместо чего
предлагается распределять наращивание функциональности и интерфейсных
возможностей по итерациям, позволяет ослабить требование переделки старого
при возвратах
В отличие от предыдущих моделей, спиральная модель предполагает
пошаговый процесс разработки ИС. При этом увеличивается количество
начальных этапов жизненного цикла (далее ЖЦ), таких как анализ и дальнейшее
проектирование. На данных этапах проверяется и проводится обоснование
реализуемости технических решений путем разработки прототипов системы.
58
Каждая итерация является законченным циклом разработки, которая
приводит к выпуску внешней или внутренней версии программного изделия,
которое совершенствуется со временем от итерации к итерации, чтобы стать
полностью готовой системой.
Таким образом, каждый виток спиральной модели соответствует
разработки версии или фрагмента программного изделия, на нем происходит
уточнение цели и характеристик проекта, определение его качеств,
планирование работ следующего витка спирали. На каждой итерации ЖЦ
углубляются и конкретизируются детали данного проекта, в результате чего
выбирается вариант, который затем доводится до окончательной реализации.
Применение спиральной модели позволяет осуществлять переход на
следующий этап выполнения проекта, не дожидаясь полного завершения работы
на текущем этапе, всю недоделанную работу всегда можно будет выполнить на
следующем шаге. Главной задачей каждой итерации является как можно
быстрее создать работоспособное ПО, которое можно показать пользователям.
Таким образом, существенно облегчается процесс внесения дополнений и
уточнений в проект.
Спиральный подход к разработке программы позволяет не только
преодолеть огромное количество тех недостатков, которые порождает каскадная
модель и, помимо этого, данный подход обеспечивает ряд дополнительных
возможностей, тем самым делая процесс разработки более гибким.
Рассмотрим преимущества использование данного подхода при
разработке ПО более подробно:
− итерационная (или шаговая) разработка при изменении требований
заказчика очень сильно упрощает внесение изменений в проект;
− при применении спиральной модели в единое целое постепенно
интегрируются отдельные элементы ИС. То есть при шаговом подходе
интеграция в системе производится фактически непрерывно. Так как интеграция
систем начинается с меньшего количества элементов, то при ее проведении
появляется гораздо меньше проблем.
− уменьшение уровня рисков. Это преимущество является следствием
выше описанного преимущества, так как риски можно обнаружить только во
59
время интеграции. Поэтому уровень рисков является максимальным в начале
разработки проекта. По мере разработки ПО ожидаемые риски уменьшаются.
Данное утверждение является справедливым при любой модели разработки ПО,
однако при применении спиральной модели с наибольшей скоростью
происходит уменьшение уровня рисков. Все это напрямую связано с тем, что
при данном подходе выполнение интеграции происходит уже на самом первом
шаге. И при выполнении начальных итераций выявляются многие различные
аспекты проекта - пригодность применяемых инструментальных средств и ПО,
квалификация разработчиков и так далее. итерационная разработка способствует
обеспечению большей гибкости в управлении проектом, предоставляя
разработчикам возможность внесения в разрабатываемое изделие каких-либо
тактических изменений;
− спиральная модель предоставляет возможность получения более
надежной и устойчивой системы. Это связано с тем, что по мере развития
информационной системы слабые места и ошибки обнаруживаются и
исправляются на каждом шаге. Сразу одновременно могут вноситься
корректировки и критические параметры эффективности, что при применении
каскадной модели выполняется только перед самым внедрением системы;
− шаговый подход способствует повторному применению компонентов
(позволяет применять к программированию компонентный подход). Все это
обусловлено тем, что намного проще выявить какие-либо общие части проекта,
когда они уже разработаны хотя бы частично, чем в самом начале проекта
пытаться определить их;
− итерационный подход способствует совершенствованию процесса
разработки — анализ, который проводится в конце каждого шага, позволяет
проводить оценку того, какие изменения в организации разработки должны
быть, и улучшить ее на следующем шаге.
Основной проблемой спирального ЖЦ при этом является определение
момента перехода на следующий этап. Для решения данной проблемы
необходимо определить временные ограничения на каждый из этапов ЖЦ. В
противном случае процесс разработки ПО может превратиться в бесконечное
совершенствование уже сделанных работ. Поэтому завершение итерации
60
должно происходить в строгом соответствии с планом, даже тогда когда не вся
запланированная работа закончена.
Для разработки ИС «Управленческий учет» группы компаний «СТЕК»
будет использован спиральный жизненный цикл, так как он способствует
сокращению времени разработки ПО за счет рисков выявленных на ранних
этапах.
На сегодняшний день выделяют несколько стратегий внедрения
разрабатываемой ИС «Управленческий учет» группы компаний «СТЕК»:
А) Стратегия «Параллельное использование», которая подразумевает
параллельное выполнение старой и новой технологии решения задачи, их
результаты сравниваются. Если результаты согласуются длительное время, то
осуществляется переход на новую технологию.
Б) Стратегия «Скачок». Скачок − старая технология работает до
определенного момента, затем осуществляется внедрение новой технологии, а
после внедрения реализуется только новая технология
В) Стратегия «Пилотный проект». Пилотный проект − тактика скачка
применяема к ограниченному числу процессов, областью применения обычно
является небольшой участок.
Г) Стратегия «Узкое место». Узкое место − автоматизация малой части
производственного процесса, который обычно выбирается по критериям, их
эффективности приводящих к повышению качества реализации процессов
только в определенном узком месте.
Рассмотрим достоинства и недостатки стратегии внедрения
разрабатываемой ИС «Управленческий учет» группы компаний «СТЕК»
(таблица 11).
Таблица №11
Сравнение стратегий внедрения ИС «Управленческий учет» группы
компаний «СТЕК»
Вид стратегии
Достоинства
Недостатки
Параллельное
использование
− минимальный риск ошибок в
виде новых технологий;
− управления внедрения ИС
− двойная загрузка персонала;
− потребности в удвоенных
мощностях серверов;
61
может осуществлять
независимо от обычного
операционного планирования.
− необходимость постоянной
сверки результатов работы.
Скачек
− минимальная длительность
переходного периода;
− отсутствие двойных затрат
при деятельности компании;
− новые процессы являются
наиболее оптимальными в
виду отсутствия переходного
периода.
− высокие риски
несоответствия качества ИС
требованиям компании;
− высокие требования к
процессу планирования
перехода на новую
технологию;
Пилотный
проект
− минимальный риск выбора
неверного решения, которое не
приводит к длительному
простою всего предприятия;
− возможность изменения
планируемой технологии в
процессе внедрения ИС на
участке;
− отсутствие двойных затрат
на реализацию технологии.
− сложность интеграции
информационных потоков
формируемых по старой и
новой технологии;
− необходимость управления
старой и новой ИС
одновременно.
Узкое место
− после автоматизации
каждого узкого места имеется
возможность прервать
автоматизацию;
− минимальные требования к
уровню планирования работ
внедрения.
− выполнение полного цикла
планирования на каждом из
узких мест, ввиду
возможности прерывания
автоматизации процесс может,
не закончится некогда;
−независимость
автоматизации может
привести к формированию
избыточного множества
программно-аппаратных
62
решений.
Таким образом, в условиях ограниченного бюджета и начальной
стадии внедрения разработанной ИС логичным будет выбрать стратегию
автоматизации «Параллельное использование».
Для решение поставленной задачи был выбран стандарт ЖЦ ИС ISO/IEC
12207 так как распространяется на все виды заказного ПО.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Любой проект по разработки ИС всегда включает в себя множество
различных задач, которые связанны с общим управлением проекта,
разработкой, проектированием и внедрением ИС. Каждая из этих задач, сама по
себе является проектом с присущими ему особенностями. Поэтому в ходе
разработки ИС существуют различные риски. Рассмотрим их.
Основным риском на подэтапе «Определение требований к ИС
«Управленческий учет» группы компаний «СТЕК» является неполное
определение свойств и функций разрабатываемой ИС, которые требуются для
решения поставленной задачи, а также полностью неправильный выбор задачи
проектирования. Из-за описанных выше рисков на этапе эксплуатации ИС может
потребоваться ее доработка, что приведет к дополнительным финансовым
потерям. Данный риск можно предотвратить при помощи современных case-
средств для моделирования всех бизнес-процессов. При возникновении данного
риска необходимо провести дополнительное моделирование.
На подэтапе «Определение функций ИС «Управленческий учет» группы
компаний «СТЕК» и стратегии автоматизации» основным риском является не
только неправильное выявление функций разрабатываемой ИС и стратегии
автоматизации, но и риск выбора неправильного способа приобретения ИС.
который предотвращается глубоким анализом всех существующих вариантов.
Данный риск можно предотвратить при помощи повторного анализа вариантов
выбора ИС.
Основным риском подэтапа «Разработка проекта автоматизации» является
разработка неэффективного плана-графика автоматизации, следствием которого