CC BY
108
УДК 65.011.56
ОРГАНИЗАЦИОННЫЕ АСПЕКТЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
SOFTWARE DEVELOPMENT STEPS
М.В. Гладких, С.Н. Кужева S.N. Kuzheva, M.V. Gladkikh
Омский государственный университет им. Ф.М. Достоевского
Рассмотрены отдельные стадии разработки программного обеспечения: начальная, уточнения, конструирования и ввода в действие. Раскрыто содержание продуктов жизненного цикла программного обеспечения: комплектов управления, требований, проектирования, реализации и внедрения.
The article determines software development stages as follows: initiation, elaboration, design, installation. It also describes software life-cycle products: control complex, specifications, designing, and implementing.
Ключевые слова: рабочий продукт разработки, комплекты требований, проектирования, реализации, внедрения и управления.
Key words: development product, specification complex, design, implementation, control.
Характеристикой, в наибольшей степени определяющей успешность процесса создания программного обеспечения (ПО), является четко определенное разграничение между работами по исследованию и анализу и работами по производству, т. е. рассмотрение процесса по стадиям жизненного цикла разработки [1]. Современные успешные проекты обычно имеют хорошо обозначенную основную контрольную точку в осуществлении проекта, по достижении которой происходит осязаемый переход от состояния исследований к состоянию производства. Более ранние стадии сосредоточены на обретении функциональных возможностей, более поздние стадии касаются получения продукта, который может быть передан заказчику.
Для большинства традиционных (водопадных) жизненных циклов разработки стадии получают название по главному виду деятельности, осуществляемому в рамках каждой стадии: анализ требований, разработка, кодирование, тестирование модулей, интеграционное тестирование, тестирование системы. Особое внимание уделяется в основном последовательности процесса, когда требуется сначала завершить один вид деятельности, затем начать следующий. В случае итерационного процесса каждая стадия включает в себя все виды деятельности в разных пропорциях.
Каждая из стадий ставит перед командой разработчиков определенные цели (таблица 1),
которые требуют достижения соответствующих критериев.
Первоочередной задачей начальной стадии является достижение согласованности между заинтересованными сторонами относительно целей всего жизненного цикла проекта.
Стадия уточнения является наиболее критичной из всех стадий. По ее окончании «разработка» считается завершенной, и должно быть принято решение, переходить или не переходить к стадиям производства. Для большинства проектов это решение соответствует переходу от «легких» действий с малым финансовым риском к действиям с более высоким финансовым риском и существенной инерцией.
На стадии конструирования все компоненты и функциональные возможности интегрируются в одно приложение и все функциональные возможности тщательно тестируются. По мере необходимости интегрируется также вновь разработанное ПО. Эта стадия представляет собой процесс производства, в котором особое внимание уделяется управлению ресурсами и контролю над выполнением с целью оптимизации стоимости, сроков и качества. В этом смысле общая направленность менеджмента претерпевает изменения, эволюционируя от разработки интеллектуальной собственности в течение начальной стадии и стадии уточнения в сторону разработки коммерческих продуктов в процессе конструирования и ввода в действие.
© М.В. Гладких, С.Н. Кужева, 2010
Таблица 1
Цели и критерии отдельных стадий разработки ПО
Стадия Цели Критерии оценки окончания стадии
Начальная Определение области проекта. Выявление критичных вариантов использования. Оценка стоимости и сроков. Оценка рисков Все ли согласны с определением области действия и с оценками стоимости и сроков? Понятны ли требования? Действительно ли реальные затраты ресурсов приемлемы по сравнению с планируемыми затратами?
Уточнение Определение общей концепции. Определение базовой архитектуры. Определение плана конструирования Является ли общая концепция стабильной? Является ли стабильной архитектура? Все ли заинтересованные лица согласны с тем, что данная концепция может быть реализована в контексте заданной архитектуры?
Конструирование Минимизация стоимости разработки за счет оптимизации использования ресурсов и исключения излишних дефектов и доработок. Достижение требуемого качества настолько быстро, насколько это практически осуществимо. Создание полезных версий (альфа-, бета- и других тестовых версий) настолько быстро, насколько это практически осуществимо Является ли основа продукта достаточно сформировавшейся для передачи его пользователям? Является ли основа продукта достаточно стабильной для передачи его пользователям? Готовы ли заинтересованные стороны к передаче продукта пользователям? Являются ли реальные затраты ресурсов приемлемыми по сравнению с планируемыми затратами?
Ввод в действие Достижение самостоятельной поддержки системы со стороны пользователей. Достижение согласия между заинтересованными сторонами относительно того, что внедряемый продукт завершен и не противоречит критериям оценки, определенным в концепции. Создание окончательной версии продукта настолько быстро и настолько дешево, насколько это осуществимо на практике Удовлетворены ли пользователи? Являются ли реальные затраты ресурсов приемлемыми по сравнению с планируемыми затратами?
Стадия ввода в действие наступает, когда основа продукта оказывается достаточно сформировавшейся для установки системы у конечных пользователей. Для этого обычно требуется, чтобы применяемое подмножество системы было выполнено с приемлемым уровнем качества и пользовательской документацией, тогда передача приведет к положительным результатам. Стадия ввода в действие заканчивается, когда продукт оказывается полностью внедренным. Для некоторых проектов окончание жизненного цикла может совпадать с отправной точкой следующей версии проекта.
Большинство описаний процесса в качестве главного способа его представления использует последовательность выполнения работ. С точки зрения отдельной личности все виды работ сугубо последовательны. Однако простые последовательности работ совершенно нереальны для проектов по созданию ПО,
реализуемых командой. Распределенный характер процесса по созданию ПО и зависящие друг от друга рабочие процессы являются основным источником сложности управления.
Один из пороков традиционного процесса создания ПО заключается в представлении макропроцесса жизненного цикла в виде последовательно выполняемых работ: от анализа требований к проектированию, кодированию, тестированию и внедрению. Но при любой последовательности работ по созданию ПО многие виды деятельности выполняются параллельно. Например, анализ требований не является одним непрерывным аккордом; он пересекается с управлением проектом, проектированием, реализацией и т. д.
При итеративной разработке каждая из стадий состоит из одной или большего числа итераций, в которых какая-либо из технических возможностей создается в виде, пригод-
ном для демонстрации, и оценивается по некоторому набору критериев. Итерация представляет собой последовательность действий, для которых существует четко определенное промежуточное событие - контрольная точка. Рамки и результаты каждой итерации фиксируются посредством отдельных рабочих продуктов. В итерациях на начальной стадии и стадии уточнения основное внимание уделяется управлению проектом, требованиям и проектированию. В итерациях на стадии конструирования основное внимание уделяется проектированию, реализации и оценке. В итерациях на стадии ввода в действие основное внимание уделяется оценке и внедрению.
Переход от одной стадии к следующей больше напоминает принятие определяющего решения, чем завершение того или иного этапа разработки ПО. Эти внутренние переходы от одной стадии к другой являются главными анкерными точками процесса создания ПО, когда приводятся в соответствие технические и управленческие перспективы, а между всеми исполнителями достигается согласие на базе текущего понимания требований, разработки и планов по завершению.
В этой связи выделяют [1] семь основных процессов разработки:
- процесс управления проектом: контроль за ходом работ и гарантия условий достижения успеха для всех заинтересованных сторон;
- процесс создания рабочей среды: автоматизация процесса и развитие среды сопровождения и эксплуатации;
- процесс управления требованиями: анализ проблемной области и совершенствование рабочих продуктов требований;
Выбор комплектов управления, требований, проектирования, реализации и внедрения не является научно обоснованным. Основная задача при определении комплектов - оптимизация представления процессов, рабочих продуктов и целей процесса.
Комплекты рабочих продуктов в общем виде разделяются на две области: комплекты
- процесс проектирования: моделирование решения и совершенствование архитектуры и рабочих продуктов проектирования;
- процесс реализации: программирование компонентов и совершенствование рабочих продуктов реализации и внедрения;
- процесс оценки тенденций и качества продукта;
- процесс внедрения: передача конечных продуктов пользователю.
Рабочим продуктом процесса разработки является дискретная связанная совокупность информации, обычно разрабатываемая и рассматриваемая как единое целое. В традиционных проектах по созданию ПО основное внимание уделяется последовательной разработке рабочих продуктов: формулировке требований, конструированию проектной модели, созданию реализации, компиляции и тестированию реализации для последующего внедрения.
Продукты жизненного цикла ПО организованы в виде пяти отдельных комплектов (деление осуществлено по языку, на котором написаны документы, входящие в комплект) (рис.):
• управление (специальные текстовые форматы);
• требования (организованный текст и модели проблемной области);
• проектирование (модели области решений);
• реализация (понятный человеку язык программирования и соответствующие исходные файлы);
• внедрение (машинные языки и соответствующие файлы).
разработки и комплект управления. Содержание и взаимосвязь рабочих продуктов представлены в таблицах 2 и 3.
Комплекты разработки состоят из комплекта требований, проектного комплекта, комплекта реализации и комплекта внедрения.
Комплект управления (декомпозиция работ, бизнес-план, спецификация версий, план разработки, описание версий, оценка состояния, база изменений, документация по внедрению, среда)
Комплект требований (концепция, модели требований) Комплект проектирования (проектные модели, тестовая модель, архитектура) Комплект реализации (исходный код, файлы для компиляции, исполняемые компоненты) Комплект внедрения (базовый продукт, файлы для выполнения, руководства пользователя)
Рис. Комплекты рабочих продуктов разработки ПО
Таблица 2
Комплекты разработки
Название Содержание комплекта
Комплект требований Использование структурированного текста для описания общей концепции системы позволяет документировать область действия проекта. Это главный рабочий контекст для определения других комплектов, касающихся разработки, на его основе формируются тестовые варианты
Комплект проектирования Представлены различные уровни абстракции, которые соответствуют различным компонентам из области решений (их индивидуальные свойства, атрибуты, статические связи и динамические взаимодействия). В этих моделях содержится достаточное количество информации о структуре и поведении для определения спецификации рабочих продуктов
Комплект реализации Включает исходный код (запись на языке программирования), который представляет собой реализации компонентов (их форму, интерфейс и зависимости), и все исполняемые файлы, требуемые для автономного тестирования компонентов
Комплект внедрения Содержит файлы, поставляемые пользователю, записи на машинном языке, исполняемое ПО, сценарии сборки, сценарии инсталляции и данные, необходимые для использования продукта в той среде, для которой он предназначен. Записи на машинных языках представляют компоненты продукта в конечном виде, служащем для распространения среди пользователей
Комплект управления содержит рабочие продукты, связанные с планированием процесса и его осуществлением. В этих продуктах используются специализированные нотации, включая текст, графику или любое другое пред-
Рабочие продукты
ставление, необходимое для того, чтобы зафиксировать принятые соглашения среди сотрудников, работающих над проектом, и заинтересованных лиц.
Таблица 3
плекта управления
Название Содержание
Декомпозиция работ Это средство для определения и получения бюджета представляет собой разбиение всех выполняемых задач по типовым направлениями и является индивидуальной для каждой компании
Бизнес-план Содержит всю информацию, необходимую для выяснения того, стоит ли инвестировать в данный проект. Основной задачей является превращение общей концепции системы в экономические термины с тем, чтобы организация могла произвести точную оценку Я01
Спецификации версии Содержание итераций, измеримые цели, демонстрационный план и сценарии функционирования
План разработки ПО Превращает схему процесса в максимально детализированный план. Должен соответствовать контракту и стандартам организации, изменяться параллельно с изменением проекта и требований и использоваться непротиворечивым образом всеми нижестоящими организациями, занятыми созданием ПО
Описания версии Приводятся результаты по каждой версии, включая оценку работоспособности по каждому из критериев оценки, содержащихся в соответствующих спецификациях версии
База данных запросов на изменение ПО Свобода внесения изменений достигается за счет автоматизации, а все бремя по управлению изменениями ложится на современную среду итерационного процесса разработки. Организационные процессы, зависящие от ручных методов управления изменениями, неэффективны. За счет автоматизации ввода данных и поддержки записей об изменениях в онлайновом режиме может быть автоматизирована большая часть бюрократической деятельности по управлению изменениями, сбору метрик и составлению отчетов
Рабочие продукты внедрения Могут включать несколько подмножеств документов для перевода продукта в рабочее состояние: рабочие руководства по компьютерной системе, руководства по инсталляции системы, маркетинговые планы, средства запуска в продажу и курсы обучения и т. п.
Среда разработки Включает управление требованиями, визуальное моделирование, автоматизацию ведения документации, средства программирования для клиента и сервера, автоматизированное регрессионное тестирование, интегрированное управление изменениями и отслеживание дефектов
Организация разработки ПО предполагает осуществление нескольких стадий: начальной, уточнения, конструирования и ввода в действие. Каждой из стадий соответствует создание набора специализированной информации - рабочего продукта разработки, которые называются соответственно комплектами требований, проектирования, реализации, внедрения и управления. В современном процессе стараются не давать стадиям названия в соответствии с доминирующими видами деятель-
ности. Названия стадий скорее определяют состояние проекта, чем последовательность действий, аналогичную водопадной модели. Делается это с намерением явно признать непрерывность работ на всех стадиях и отойти от последовательного движения.
1. Ройс У. Управление проектами по созданию программного обеспечения. - М.: Лори, 2006.
