МОДЕЛЬ НЕПОЛНОГО ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Авторы:
1.
Сибирский государственный индустриальный университет
(старший преподаватель кафедры автоматизации и информационных систем)
Россия
Россия
2.
Сибирский государственный индустриальный университет
(старший преподаватель кафедры автоматизации и информационных систем; ведущий специалист по информатизации отдела системных и сетевых технологий)
3.
Сибирский государственный индустриальный университет
(д-р техн. наук, профессор; профессор кафедры автоматизации и информационных систем)
Тип:
Статья
Страницы:
с 65
по 70
Статус:
Опубликован
Получено:
05.04.2015
Одобрено:
25.04.2015
Опубликовано:
25.04.2015
Классификаторы:
ВАК 05.12.2013 Системы, сети и устройства телекоммуникаций
ВАК 05.13.01 Системный анализ, управление и обработка информации (по отраслям)
ВАК 05.13.06 Автоматизация и управление технологическими процессами и производствами (по отраслям)
ВАК 05.13.10 Управление в социальных и экономических системах
ВАК 05.13.18 Математическое моделирование, численные методы и комплексы программ
ВАК 05.13.19 Методы и системы защиты информации, информационная безопасность
УДК 004.04
ГРНТИ 20.01 Общие вопросы информатики
ГРНТИ 28.01 Общие вопросы кибернетики
ГРНТИ 49.01 Общие вопросы связи
ГРНТИ 50.01 Общие вопросы автоматики и вычислительной техники
ГРНТИ 82.01 Общие вопросы организации и управления
ВАК 05.13.01 Системный анализ, управление и обработка информации (по отраслям)
ВАК 05.13.06 Автоматизация и управление технологическими процессами и производствами (по отраслям)
ВАК 05.13.10 Управление в социальных и экономических системах
ВАК 05.13.18 Математическое моделирование, численные методы и комплексы программ
ВАК 05.13.19 Методы и системы защиты информации, информационная безопасность
УДК 004.04
ГРНТИ 20.01 Общие вопросы информатики
ГРНТИ 28.01 Общие вопросы кибернетики
ГРНТИ 49.01 Общие вопросы связи
ГРНТИ 50.01 Общие вопросы автоматики и вычислительной техники
ГРНТИ 82.01 Общие вопросы организации и управления
Язык материала:
русский
Ключевые слова:
жизненный цикл, модель, версия, программное обеспечение
Аннотация (русский):
Разработка крупных программных проектов требует значительных усилий. Известные нормативные модели полного жизненного цикла, применяющиеся крупными компаниями, охватывают все стадии и этапы жизни проекта и, в конечном счете, значительно увеличивают затраты на разработку. По мере роста сложности проектов возникает необходимость в использовании технологического процесса, который позволит более гибко реагировать на запросы заказчиков и уменьшить затраты. Рассматривается модель неполного жизненного цикла программно-технического обеспечения, основанная на итерациях и тестировании, пригодная для использования мобильными коллективами программистов в условиях жесткой оптимизации затрат и ресурсов. Приведенный подход опирается на принятую в системном анализе вход-выходную модель «черного ящика», которая приобретает функциональность в процессе разработки в соответствии с бизнес-требованиями. Главное отличие от других нормативных моделей жизненного цикла программного обеспечения заключается в акцентировании внимания разработчиков на постоянно меняющихся потребностях заказчиков. Учитываются ситуации, когда все заинтересованные стороны непрерывно уточняют свое видение архитектуры и функций системы. Следуя закономерным тенденциям развития программного обеспечения, предлагаемая модель неполного жизненного цикла опирается на элементы гибкой разработки, в частности, разработки, управляемой тестированием, когда прикладной инструментарий позволяет органично встраивать в проекты модульные тесты.
Разработка крупных программных проектов требует значительных усилий. Известные нормативные модели полного жизненного цикла, применяющиеся крупными компаниями, охватывают все стадии и этапы жизни проекта и, в конечном счете, значительно увеличивают затраты на разработку. По мере роста сложности проектов возникает необходимость в использовании технологического процесса, который позволит более гибко реагировать на запросы заказчиков и уменьшить затраты. Рассматривается модель неполного жизненного цикла программно-технического обеспечения, основанная на итерациях и тестировании, пригодная для использования мобильными коллективами программистов в условиях жесткой оптимизации затрат и ресурсов. Приведенный подход опирается на принятую в системном анализе вход-выходную модель «черного ящика», которая приобретает функциональность в процессе разработки в соответствии с бизнес-требованиями. Главное отличие от других нормативных моделей жизненного цикла программного обеспечения заключается в акцентировании внимания разработчиков на постоянно меняющихся потребностях заказчиков. Учитываются ситуации, когда все заинтересованные стороны непрерывно уточняют свое видение архитектуры и функций системы. Следуя закономерным тенденциям развития программного обеспечения, предлагаемая модель неполного жизненного цикла опирается на элементы гибкой разработки, в частности, разработки, управляемой тестированием, когда прикладной инструментарий позволяет органично встраивать в проекты модульные тесты.
Ключевые слова:
жизненный цикл, модель, версия, программное обеспечение
жизненный цикл, модель, версия, программное обеспечение
Введение Многие формализованные подходы, в частности спиральная и каскадная (водопадная) модель [1], предусматривают последовательное прохождение программного продукта по определенным этапам жизненного цикла (ЖЦ): постановка задачи, анализ рисков, анализ требований, построение проектных спецификаций, проектирование, реализация, тестирование, ввод в эксплуатацию и сопровождение, вывод из эксплуатации. Такие громоздкие нормативные модели в условиях оперативных изменений требований заказчиков на практике создают проблемы, для решения которых изначально не были предназначены. Зачастую снижение производительности коллектива разработчиков влечет за собой изменение графика работ и увеличение бюджета проекта. Сама идеология предварительного алгоритмического проектирования изначально предполагает отсутствие гибкости, «монолитность» документации и первоначального кода, т. к. разработчики не всегда могут оперативно реагировать на изменения требований заказчика. К сожалению, многие коллективы разработчиков считают, что процесс создания программного обеспечения (ПО) пока еще является недостаточно всеобъемлющим и формализованным, тем самым они способствуют неконтролируемому росту разнообразных стандартов проектирования, диаграмм, нотаций и спецификаций. Так, например, стандарт UML 2.0 (Unified Modeling Language) [2] предусматривает возможность использования 14 типов диаграмм, из которых на практике обычно используется не больше половины. Недостатки применения моделей полного жизненного цикла Современная разработка сложного ПО и объектно-ориентированный подход предполагают в первую очередь наличие гибкой и масштабируемой архитектуры, способной оперативно реагировать на изменения потребностей заказчика в условиях, когда сам заказчик не всегда способен четко сформулировать требования к системе на этапе проектирования. Действительно, откуда заказчик может взять требования к пользовательскому интерфейсу приложения, когда обычно на практике эти требования должны эволюционировать в соответствии с пожеланиями постоянных пользователей? Откуда заказчик может знать заранее, какой интерфейс ему будет нужен? Более того, недостаточная обратная связь на стадии программирования ведет к неконтролируемому росту затрат при сопровождении. Очевидно, что большинство моделей полного ЖЦ в достаточной степени избыточны, неэффективны и слишком дороги для использования в условиях конкурирующего и динамично развивающегося рынка ПО. В конечном счете, документация и диаграммы никогда не смогут устранить архитектурные недостатки дизайна системы, а также учесть постоянное накопление и развитие опыта разработчика. Гибкие методики разработки ПО Гибкие методики, такие как Crystal [2], Scrum [3], XP [2, 4], предусматривают быструю поставку начальной версии работающей программы заказчику для тестирования, игнорируя на начальном этапе многие проектные требования и подразумевая последующее расширение функциональности программы. Основная цель - обеспечение непрерывности развития проекта с возможностью оперативного реагирования на изменения требований бизнеса. Тяжеловесные модели полного ЖЦ слишком неуклюжи, чтобы предусмотреть полный пересмотр заказчиком своего «видения» на этапе завершения проекта. Гибкие методики предлагают коллективам разработчиков ПО сконцентрироваться на качестве выпускаемого продукта в ущерб документации и прочим артефактам проектно-процессной деятельности. Программный продукт выпускается короткими итерациями, каждая из которых заканчивается определенной сборочной версией, которая поступает в эксплуатацию, а также используется заказчиком для уточнения требований и предварительного тестирования. Разработчики и заказчики формируют сроки и бюджет каждой итерации, оценивая предыдущие достигнутые результаты и требуемый прирост функционала от версии к версии. При этом предварительный сбор детальной информации о требованиях к системе, принятый в моделях полного ЖЦ будет пустой тратой времени и сил, поскольку конечная реальность может оказаться другой. Конкретные детали требований со временем могут и должны изменяться в процессе взаимодействия с ответственным представителем заказчика. В связи с этим в практической деятельности целесообразно оперировать понятиями ЖЦ отдельной сборочной версии или итерации, что позволит сконцентрировать видение заказчиков и разработчиков на функциональном, более узком аспекте деятельности ИТ-коллективов, связанных в первую очередь с разработкой ПО. Таким образом, в гибкой разработке этапы проектирования, программирования и сопровождения непрерывны, неотделимы друг от друга и входят в состав отдельной короткой итерации разработки. Модель неполного ЖЦ ПО Предложена модель неполного жизненного цикла, которая основана на последовательном уточнении архитектуры программного комплекса, представленной, исходя из основополагающих принципов системного анализа, в виде «серого ящика» на i-й итерации изменения бизнес-требований. Нулевая итерация представляет собой пустую сборочную версию r(Ø), компоненты которой не определены. Обозначим одно бизнес-требование как , где формирует пространство всех требований заказчика. Таким образом, совокупность бизнес-требований (заказчика) для i-й итерации проектных изменений можно описать вектором (Business Requirements), где i изменяется от 1 до некоторого k, определяющего стадию ввода в эксплуатацию программного продукта. В условиях трасформации требований, когда некоторое их подмножество остается неизменным, а другое «уточняется», измененные требования можно представить как - уточнение и детализация заказчиком своих пожеланий. Необходимо отметить, что некоторые координаты вектора изменений равны нулю, т. к. изменения соответствующего не требуются. Для каждого необходимо произвести рефакторинг кода и выполнить тестирование, поэтому вектору однозначно соответствует вектор на i-м шаге уточнения требований. На вход ящика поступают изменения , обусловленные текущими требованиями заказчика и оформленные в виде новых бизнес-потребностей - самых общих соображений по поводу функциональности, без фиксации конкретных деталей. Выходы «серого ящика» отражают прохождение (или непрохождение) тестов функциональности, используемых для актуализации архитектуры системы в рамках необходимых требований. Таким образом, на каждой итерации происходит уточнение «черного ящика» до тех пор, пока он не превращается в «белый ящик», пригодный для промышленного использования (рис. 1). Рис. 1. Модель неполного ЖЦ итерации сборочной версии Обозначим Rp = {ri |iI} как множество сборочных версий одного проекта, последовательно формируемых разработчиком в процессе уточнения бизнес-требований заказчика; p - номер проекта. Также обозначим одну сборку как , тогда начальную сборку как r(Ø). Таким образом, начальную итерацию можно рассматривать как реализацию изменений требований относительно «черного ящика». На рис. 2 показаны два проекта, для каждого из которых наблюдается собственная линия сборок. Рис. 2. Итерационная модель ЖЦ сборочной версии По аналогии с версионной моделью ЖЦ услуги, представленной в [5], приведем итерационную модель ЖЦ сборочной версии ПО. Итерационная модель услуги описывает эволюцию отдельных версий сервиса по стадиям ЖЦ ITIL [6], к которым относится стратегия, проектирование, трансформация и эксплуатация услуг. Предлагаемая нами модель, в отличие от версионной [5], позволяет с максимальной степенью адаптировать разработку ПО под постоянно изменяющиеся потребности заказчика в условиях значительной неопределенности. Модель ЖЦ сборочной версии опирается на современные тенденции в индустрии ПО, в частности, на управляемую модель на основе разработки [2, 4], паттерны проектирования [2] и поддерживается большинством сред разработки промышленного масштаба, таких как MS Visual Studio и Oracle JDeveloper. Процедура последовательного улучшения программно-технического обеспечения включает в себя учет добавленных (или изменяющихся) бизнес-требований для каждой i-й итерации формирования очередной сборочной версии (рис. 3). Неполная модель ЖЦ ПО, опробованная нами в проектах [7-9], подходит для разработки крупных программных систем в условиях оптимизации затрат. Сравнение подходов к разработке производилось на основе двух подобных проектов, выполненных в 2014 г. в Сибирском государственном индустриальном университете. Рис. 3. Процедура последовательного (итерационного) улучшения ПО Первый проект использовал спиральную модель полного ЖЦ, в котором наряду со штатными сотрудниками принимали участие сторонние разработчики. Он представляет собой web-сайт университета (http://www.sibsiu.ru), выполненный на базе системы управления CMS 1C «Битрикс». Проект прошёл множество (около 20) полных спиралей разработки: - оценка и разрешение рисков; - определение целей; - разработка и тестирование; - планирование и т. д. А также все необходимые этапы: - написание технического задания; - выбор, закупка и установка CMS; - разработка макета дизайна (сторонние специалисты); - вёрстка шаблона; - разработка инфоблоков и дополнительный модулей для CMS «Битрикс»; - наполнение сайта (перенос информации со старого сайта); - обучение персонала; - написание отчёта. Общее время разработки составило около 6 месяцев при работе двух программистов, одного дизайнера, двух контент-менеджеров и сторонних специалистов. Второй проект - система мониторинга эффективности деятельности университета (http://monitoring.sibsiu.ru) - был выполнен полностью «с нуля» силами штатных разработчиков с применением модели неполного ЖЦ. В связи с мобильностью группы разработки и близостью к заказчику у разработчиков была возможность постоянного уточнять цель и задачи, что позволило избежать большого количества итераций разработки. Проект прошёл примерно 12 итераций уточнения требований и следующие этапы: - первичная постановка цели; - разработка макета дизайна; - вёрстка шаблона; - разработка функционала; - обучение персонала; - написание отчёта. Техзадание было кратким, отражающим только цели разрабатываемой системы, поэтому степень неопределённости и риски срыва сроков проекта были высоки. Вся работа была выполнена за 4 месяца силами трех человек. Заключение Дано описание модели неполного ЖЦ программно-технического обеспечения, основанной на итерациях и тестировании, пригодной для использования мобильными коллективами программистов в условиях оптимизации затрат и ресурсов. Приведенный подход опирается на принятую в системном анализе вход-выходную модель «черного ящика», которая приобретает функциональность в процессе разработки в соответствии с бизнес-требованиями.
1. Рассел Дж. Жизненный цикл программного обеспечения / Дж. Рассел // Bookvika Publishing, 2012. 89 с.
2. Мартин Р. С. Agile software development / Р. С. Мартин, Дж. В. Ньюкирк, Р. С. Косс // Principles, Patterns and Practicies Principles, Patterns and Practicies. М.: Вильямс, 2004. 752 с.
3. Cohn Mike. Scrum: Succeedind with Agile: Software Development Using Scrum (Addison-Wesley Signature Series). М.: Вильямс, 2011. 576 с.
4. URL: http://www.jot.fm/books/review7.pdf.
5. Зимин В. В. Основы управления жизненным циклом сервиса систем информатики и автоматизации (лучшие практики ITIL): учеб. пособие / В. В. Зимин, А. А. Ивушкин, С. М. Кулаков, К. А. Ивушкин. Кемерово: Кузбассвузиздат, 2013. 500 с.
6. OGC-ITIL V3-6. Service Lifecycle. Introduction ITIL TSO, 2007. 173 p.
7. Добрынин А. С. О формировании комплекса инструментальных средств ИТ-провайдера для построения расписаний процесса внедрения сервиса / А. С. Добрынин, С. М. Кулаков, В. В. Зимин, Н. Ф. Бондарь // Научное обозрение. 2013. № 8. С. 93-101.
8. Койнов Р. С. Об использовании принципа согласованного управления в задачах внедрения ИТ-сервиса / Р. С. Койнов, А. С. Добрынин, С. М. Кулаков, В. В. Зимин // Вестн. развития науки и образования. 2013. № 6. С. 23-27.
9. Добрынин А. С. Формирование расписаний в задачах временного планирования / А. С. Добрынин, С. М. Кулаков, Р. С. Койнов, А. В. Грачёв // Вестн. Астрахан. гос. техн. ун-та. Сер.: Управление, вычислительная техника и информатика. 2014. № 4. С. 103-111.
