CC BY
70
2008
Доклады БГУИР
№ 8 (38)
УДК 004.05
МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ ПРИ РАЗРАБОТКЕ НА ОСНОВЕ ГИБКИХ МЕТОДОВ
ВВ. БАХТИЗИН, С.Н. НЕБОРСКИЙ
Белорусский государственный университет информатики и радиоэлектроники П. Бровки, 6, Минск, 220013, Беларусь
Поступила в редакцию 5 июня 2008
Предлагается модель жизненного цикла программных средств при разработке на основе гибких методов. Процессы жизненного цикла разделены на три стадии: инициация, итеративная реализация требований и сопровождение. Итеративная реализация требований составляет основу предлагаемой модели, причем выделяются итерации с поставкой программных средств заказчику и внутренние итерации. Предлагается разрабатывать программные средства не на основе одного конкретного гибкого метода, а на основе нескольких. Выбрано необходимое подмножество гибких методов, состоящее из гибкого моделирования, экстремального программирования и разработки, ведомой функциями. Приведены аргументы в поддержку этого выбора.
Ключевые слова: жизненный цикл программных средств, модель жизненного цикла, гибкие методы разработки.
Введение
Базовым стандартом в области жизненного цикла (ЖЦ) программных средств (ПС) является стандарт ISO/IEC 12207. В Беларуси этот стандарт введен в действие в 2004 г. под обозначением СТБ ИСО/МЭК 12207-2003. Данный стандарт определяет наличие следующих основных процессов ЖЦ: заказ, поставка, разработка, эксплуатация и сопровождение [1]. Практически любая модель ЖЦ ПС в той или иной мере описывает процессы из всего набора процессов стандарта путем включения в нее соответствующих работ и задач.
Существуют различные модели процессов ЖЦ ПС, но три из них обычно квалифицируются как фундаментальные: каскадная; инкрементная; эволюционная. Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели ЖЦ. Стандарт ИСО/МЭК 12207 определяет общий случай разработки типового проекта. При разработке конкретных проектов может отсутствовать необходимость в тех или иных процессах, работах и задачах. На рис. 1 приведен пример применения стандарта ИСО/МЭК 12207 к модели ЖЦ, основанной на макетировании (прототипировании) небольшой системы [2].
Основой эффективного применения такого макетирования системы является максимально возможная детализация на ранних стадиях проекта (анализ требований к системе и проектирование системной архитектуры). Данные стадии выполняются в ЖЦ один раз. Требования к системе, в первую очередь, функции системы и внешние функции определяются пользователями в начале ЖЦ, деловые процессы уточняются при проведении пользователем серии оценок прототипов системы [3]. Однако далеко не для всех проектов удается зафиксировать требования в самом начале ЖЦ. Зачастую в процессе реализации ПС требования меняются кардинально, от определенной уже существующей функциональности отказываются,
появляются новые требования, реализация которых предполагает изменение текущей архитектуры системы. Гибкие методы разработки как раз и призваны решать подобные проблемы [4].
Рис. 1. Пример модели ЖЦ, использующей макетирование, по ГОСТ Р ИСО/МЭК ТО 15271-2002
Модель жизненного цикла программных средств
В данной работе предлагается модель ЖЦ ПС при разработке на основе гибких методов. Эта модель, по сути, предлагает выделять три стадии разработки: инициация, итеративная реализация требований и сопровождение. На стадии инициации происходит определение концепции или потребности в системе, анализ требований к системе, проектирование системной архитектуры, рассмотрение вариантов реализации. Итеративная реализация требований - это реализация и поставка работающего ПС, где на каждой итерации реализуются новые требования и, возможно, изменяются старые. Стадия сопровождения ПС предполагает анализ обнаруживаемых проблем и внесение необходимых для их устранения изменений.
Предлагаемая модель может быть представлена в виде ориентированного графа СЛХ. У), где X = {х,, \ = \.пх }, | X |= пх — множество работ ИСО/МЭК 12207,
У = {у у, у = \,щ.}, У |= пу — множество их связей. На рис.2 приведен общий вид данного
графа, где работы X = {xj, / = 1, п х } объединены и показаны как одно целое в рамках отдельной
стадии.
Количество и типы работ, выполняемых на каждой стадии, могут корректироваться в зависимости от конкретного проекта. Могут быть изменены и связи между ними. Как результат, граф переходов работ стандарта ИСО/МЭК 12207 0(Х,У) может стать весьма сложным, что означает неэффективные, неслаженные процессы разработки ПС. В таком случае имеет смысл оптимизировать граф 0(Х, У), причем наиболее универсальным критерием оптимизации является критерий минимума числа связей между частями графа, к-я часть графа Ок — это подмножество работ стандарта ИСО/МЭК 12207 Xк с X и их подмножество связей
Ук сГ , образующих стадию в предлагаемой модели: (¡к - (Xк. Ук), к е К -{1,2,..., Nк \. где А/,
— число стадий реализации ПС. Связи между частями графа называют внешними; связи, соединяющие работы внутри отдельной стадии — внутренними.
Рис. 2. Модель ЖЦ ПС при разработке на основе гибких методов
Задача нахождения минимального количества внешних связей между отдельными стадиями сводится к оптимальному разбиению графа (¡(X. У) на части (],. — ( Xк. Ук), Xк с X , Ук с: Г . Результатом разбиения является совокупность стадий реализации 8(0)\
V Ск 6 Б(0) ,Ок * 0, к е К- \/Ск, С, е Б (О), Ок Ф01^>ХкпХ1 =0л(7, п У} = Ук1 V Ук пГ(=0), и Ск=С
кеК
(1)
Выражение (1) определяет подмножество дуг Ук1 с7, соединяющих вершины частей Ок и О: графа О. Если количество связей между частями Ок и О: графа О равно \Ук1 \=Ьк1, то общее количество внешних связей графа О (дуг, соединяющих подграфы, на которые разбит О):
1
Ш N1'
(2)
к=11=1
Для примера можно рассмотреть следующий граф (рис. 3):
Рис. 3. Пример разбиения графа
Очевидно, количество связей между частями О1, О2 и О3 таково: к12=1; Н1:3=2; к2,3=2. Тогда общее число внешних связей графа О.Н= 5. Как правило, всегда существует несколько вариантов разбиения некоторого графа (¡(X. У ) на части Ск=(Хк,Ук). Для выбора наилучшего разбиения используется коэффициент разбиения графов:
Nk j i M M Nk j
A(G) = X | Yk jk I / - Z ZI 7k,/ I = SI Yk,k | H , k=1 / 2fc=l/=l ¿fc=l /
где k — подмножество внутренних связей.
Количество внешних связей Н вычисляется по формуле (2). Сравнивая коэффициенты разбиения А(G), можно подобрать граф с минимальным количеством внешних связей, т.е. такой граф, который будет соответствовать наиболее эффективной организации ЖЦ ПС. Для графа на рис. 3 коэффициент разбиения А(G) = 2,2 . Очевидно, с ростом числа внешних связей Н коэффициент разбиения А(G) уменьшается. Следовательно, чем больше коэффициент А(G), тем лучше. Можно нормировать коэффициент А(G) с тем, чтобы он изменялся на отрезке [0, 1]. Тем самым можно ввести метрику разбиения графа :
vp= AG 1 + A(G) '
Условию —> 1 соответствует A(G) —> со,Н —> 0 . Решая на практике задачу оптимального разбиения графа, можно посчитать предлагаемую в данной работе метрику разбиения lF и определить наилучший в заданных условиях граф.
Предлагаемая в данной работе модель отводит итеративной реализации требований главную роль. Предлагается использовать два вида итераций: итерации с поставкой ПС заказчику и внутренние итерации. Внутренняя итерация предназначена главным образом для команды инженеров по качеству. Внутренние итерации показывают прогресс разработки ПС и удостоверяют отсутствие ошибок в поставляемой заказчику версии ПС.
Результатом внутренней итерации является очередная версия функционирующего ПС. Результатом внешней итерации также является версия функционирующего ПС, причем эта версия является одной из тех, что получается в результате внутренних итераций. Пусть D = ^/ = 1, т — множество всех версий ПС (т.е. множество результатов внутренних
итераций), ¿/, — внутренняя версия ПС, т - количество внутренних итераций. Тогда можно определить подмножество D' внешних версий ПС: /)' с /.),11У\= п , п — количество внешних итераций, которые были поставлены пользователям.
Для сокращения времени поставки необходимо оптимизировать функцию
поставки очередной версии ПС пользователю Т —> min.
При установленном и стабильном процессе разработки количество внутренних итераций m и количество внешних итераций п связаны линейно m = an, где а — количество внутренних итераций, образующих одну внешнюю.
Следовательно, минимальное время поставки ПС пользователю будет достигнуто при условии, что внешняя итерация содержит только одну внутреннюю итерацию m=n=1, D = D' = {dy} — множество мощности 1.
Так как на каждой внутренней итерации устраняются найденные в предыдущей версии ПС ошибки и несоответствия требованиям, то результат внешней итерации зависит от количества внутренних итераций. Следовательно, задача усложняется
minr :D—>D\ ч
где q — качество ПС.
Таким образом, разработчик и заказчик всегда вынуждены искать оптимальное время внешней итерации, результатом которой является ПС с необходимым уровнем качества.
Применение модели жизненного цикла программных средств при разработке на основе гибких методов
Предлагаемая модель предполагает, что разработка ПС ведется на основе гибких методов. Наиболее распространенными гибкими методами на сегодняшний день являются Скрум, разработка, ведомая функциями (FDD), экстремальное программирование (XP), гибкое моделирование (Agile Modeling), динамичный метод разработки систем (DSDM), разработка, ведомая тестами (TDD). Однако вряд ли удастся найти такой метод, который работал бы эффективно независимо от условий проекта. Для разработки ПС в данной работе предлагается использовать три гибких метода: гибкое моделирование, экстремальное программирование и разработку, ведомую функциями (FDD).
Когда бы ни требовалось создать архитектуру ПС, имеет смысл использовать гибкое моделирование. Получаемые модели обладают следующими свойствами: модели доступны для тех, кому они предназначены, но не обязательно для всех; они точны и непротиворечивы; модели представляют практическую ценность; они достаточно детальны и просты [5].
Гибкие методы разработки делают акцент непосредственно на реализации функциональных требований к ПС. Для эффективной реализации функциональных требований необходим набор определенных принципов и практических приемов. Именно поэтому стоит считаться с идеями XP. В основе XP лежат следующие четыре принципа: коммуникация, простота, обратная связь и требовательность к команде разработчиков, состоящей преимущественно из профессионалов [6]. Эти принципы привели к следующим идеям, составляющим основу XP [7]:
1) парное программирование;
2) всегда оставаться на связи с заказчиком;
3) тестирование упреждает разработку;
4) короткие итерации;
5) все должно быть максимально простым;
6) не разрабатывать ничего лишнего, пока не возникнет непосредственное требование заказчика;
7) коллективное владение проектом.
Безусловно, гибкое моделирование и XP способствуют эффективной разработке ПС. Существует даже такой метод, как XP масштаба предприятия (EXP — Enterprise XP), суть которого как раз состоит в объединении XP и гибкого моделирования [4]. Однако ни XP, ни гибкое моделирование не касаются планирования проекта. Но для заказчика ведь важно не только качество ПС, но также время его разработки и бюджет. Без хорошего планирования вероятность успеха любого проекта снижается многократно. FDD добавляет необходимый элемент контроля.
Согласно FDD, функция — это такое требование, реализация которого запланирована и связана с определенной активностью по его реализации. Функции связывают требования с планированием. FDD предполагает наличие жестко определенных временных рамок, которые отводятся на реализацию набора функций. Эти временные рамки, набор функций (запланированных к реализации требований), их приоритеты и определяют итерацию в FDD [8].
Таким образом, в данной работе предлагается разрабатывать ПС на основе:
1) метода гибкого моделирования, что позволяет создать архитектуру ПС;
2) метода XP, что позволяет эффективно разрабатывать ПС;
3) метода FDD, что дает управление проектом.
При постоянно изменяющихся требованиях архитектуру ПС предлагается получать исходя исключительно из требований. При этом должен использоваться метод гибкого моделирования. На его основе должны быть созданы модели, лишь поясняющие архитектуру ПС. Детальная же архитектура должна строиться на основе требований автоматически. Тогда задача получения программной архитектуры будет сведена к получению отображения требований в компоненты программной архитектуры [9]. Требования могут быть заданы в виде множества R:
Я= т{| г
= 1
где пк — количество требований; гг. = я,, е Л,./ = 1./7 , — 7-ое требование; А}- —
множество значенийу-го атрибута; «4 — количество атрибутов.
Для задания связей между требованиями Я используются матрицы трассируемости или списки трассируемости. Трассируемость требований документирует зависимости и логические связи отдельных требований и других элементов ПС [10]. Матрица трассируемости может быть представлена как квадратная матрица размерностью пк* пЯ:
М = К]«'
11, если Г: зависит от г;
где тиг =< , г^г,еЯ —требования.
0, если г - не зависит от г(:
Отдельное требование или группа логически связанных требований реализуется в виде отдельного компонента ПС. Пусть С — множество таких компонентов:
С 4 ' 1. / ?, * ,
где с7 — 7-й компонент ПС; пс — количество компонентов ПС.
Необходимо задать отображение множества требований Я в множество компонентов ПС С: Г или
/
где / = 1 ,пк .
Таким образом, программная архитектура может быть получена на основе требований. Более того, можно автоматически получать программную архитектуру на основе требований [9]. Такой подход гарантирует целостность (согласованность) требований и их реализации.
Заключение
В данной работе предложена модель ЖЦ ПС при разработке на основе гибких методов. Определены три стадии (инициация, итеративная реализация требований, сопровождение), показана их связь. Предложено разрабатывать ПС на основе трех гибких методов: гибкого моделирования, экстремального программирования и разработки, ведомой функциями. Гибкое моделирование позволяет эффективно создавать архитектуру ПС в условиях изменяющихся требований, причем получаемые модели носят поясняющий характер. Детальная же архитектура создается автоматически как прямое отображение требований в компоненты ПС. Для качественной реализации этих компонентов используются приемы и подходы экстремального программирования. Разработка, ведомая функциями, позволяет управлять созданием ПС. Практическое применение предложенной модели и выбранного подмножества гибких методов позволит эффективно разрабатывать качественные ПС.
SOFTWARE LIFECYCLE MODEL WHEN DEVELOPING WITH AGILE METHODS
V.V. BAKHTIZIN, S.N. NIABORSKI Abstract
А software lifecycle model when software is being developed with agile methods is introduced. In a nutshell of this model there are three stages: initiation, iterative requirements implementation and support. During iterative requirements implementation stage, there are two types of iterations: external (those which deliver the functioning software to end-users) and internal (those which deliver the functioning software to testing team in order to assure the necessary quality level and understand the development progress). The introduced model is supposed to be used when developing software with agile methods. Instead of using some specific agile development method, it proves the benefits of using a mix of them. To get the right software, three agile methods have been chosen: agile modeling, extreme programming and feature-driven development.
Литература
1. СТБ ИСО/МЭК 12207-2003. Информационная технология. Процессы жизненного цикла программных средств.
2. ГОСТ Р ИСО/МЭК ТО 15271-2002. Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств).
3. Бахтизин В.В., Глухова Л.А. Стандартизация и сертификация программного обеспечения: Учеб. пособие Минск, 2006.
4. Hunt J. Agile Software Construction. Springer-Verlag London Limited, 2006.
5. Ambler S., Jeffries R. Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. Wiley; 1st edition, 2002.
6. Beck K., Andres Ch. Extreme Programming Explained: Embrace Change 2nd ed., Addison Wesley, 2004.
7. Burke E., Coyner B. Java Extreme Programming Cookbook. O'Reilly Media, Inc.; 1st edition, 2003.
8. Palmer S.R., Felsing J.M. A Practical Guide to Feature-Driven Development - Prentice Hall, 2002.
9. Бахтизин В.В., Неборский С.Н. // Программные продукты и системы № 3 (75), 2006. С. 2-5.
10. Вигерс К. Разработка требований к программному обеспечению. 2004.
