Научная статья на тему 'Методология разработки программного обеспечения с использованием управляющего прототипа'

Методология разработки программного обеспечения с использованием управляющего прототипа Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
866
472
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
MANAGING PROTOTYPE (MP) / THE LEVEL OF QUALITY / MATURITY / PROTOTYPE QUALITY / MP-DEVELOPMENT / УПРАВЛЯЮЩИЙ ПРОТОТИП (УП) / УРОВЕНЬ КАЧЕСТВА / УРОВЕНЬ ЗРЕЛОСТИ / ПРОТОТИП КАЧЕСТВА / УП-РАЗРАБОТКА

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Данилин Артем Олегович

Рассматривается модель УП-разработки программного обеспечения; конкретизируются процессы проектирования, внедрения и использования управляющих прототипов. Приводятся элементы УП, их взаимосвязь и ресурсы. Описывается поэтапная разработка ПО с использованием управляющего прототипа.

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Данилин Артем Олегович

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

METHODOLOGY FOR DEVELOPING SOFTWARE USING MANAGER PROTOTYPE

The article discusses the model MP-development software; specifies the processes of design, implementation and management of prototypes, consideres the elements of the MP, their interaction and resources, describes how to develop software using MP.

Текст научной работы на тему «Методология разработки программного обеспечения с использованием управляющего прототипа»

А.О. Данилин,

Воронежский государственный технический университет

МЕТОДОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ С ИСПОЛЬЗОВАНИЕМ УПРАВЛЯЮЩЕГО

ПРОТОТИПА

METHODOLOGY FOR DEVELOPING SOFTWARE USING MANAGER PROTOTYPE

Рассматривается модель УП-разработки программного обеспечения; конкретизируются процессы проектирования, внедрения и использования управляющих прототипов. Приводятся элементы УП, их взаимосвязь и ресурсы. Описывается поэтапная разработка ПО с использованием управляющего прототипа.

The article discusses the model MP-development software; specifies the processes of design, implementation and management of prototypes, consideres the elements of the MP, their interaction and resources, describes how to develop software using MP.

Введение. Совокупность процессов разработки программного обеспечения (ПО) представляет собой сложную многоаспектную систему прохождения этапов в рамках выбранной методологии реализации проекта. Существующие на сегодняшний день методы разработки можно разделить на 3 группы: последовательные, циклические, абстрактные. Каждая группа имеет ряд особенностей, обусловленных принятой моделью реализации проекта. Для последовательных методологий базовой можно считать каскадную модель разработки; для циклических — итеративную, а для абстрактных — модель индивидуального процесса реализации. Однако, вне зависимости от используемой модели, практически для всех методологий разработка ПО начинается с определения требований, затем следуют такие этапы, как проектирование, реализация и тестирование. Завершающим этапом является внедрение или сопровождение конечного продукта.

С точки зрения обеспечения качества ПО наиболее уязвимыми являются процессы обработки требований, в числе которых требования, определённые системой качества ИСО [1]. Основная проблема заключается в возникновении противоречий реализации требований на этапах проектирования и разработки. Чем сильнее возникшие противоречия и чем позже они выявлены, тем рискованнее становится проект и тем значи-

104

тельнее снижается уровень качества продукта на данном этапе. В конечном счете, это может привести к ряду непредсказуемых последствий, в том числе и к увеличению сроков сдачи проекта. В некоторой степени предотвратить возникновение подобных ситуаций позволяет создание прототипа разрабатываемого решения. Успешный пример использования прототипирования демонстрируют методологии, построенные на базе спиральной модели жизненного цикла ПО. Важным преимуществом интеграции простых прототипов в жизненный цикл является возможность повышения эффективности управления рисками разработки и тестирования. Однако ни циклические, ни абстрактные методы на базе спиральной модели не получили достаточного распространения ввиду повышения стоимости разработки. Менее оправданными затраты становятся по причине недооценки процессов управления рисками на проекте [3].

В рамках разработки программного обеспечения (как прикладного, так и системного) необходимо решить задачи повышения эффективности процессов непосредственной реализации и процессов тестирования, как максимально трудоёмких и продолжительных по времени. Одним из вариантов решения обозначенных задач может выступать разработка методологии, базирующейся на совокупности достоинств существующих подходов и принципиально новой модели разработки ПО. Для этого, выделив основные этапы жизненного цикла ПО, добавим этапы обработки механизмов контроля и управления характеристиками разрабатываемого продукта. Реализовать обозначенные функции предлагается с помощью некой программной конструкции, которую условно назовём управляющим прототипом (УП). Управляющий прототип будет представлять собой образ (проекцию) конечного решения реального продукта или всего проекта и являться примитивной реализацией совокупности требований (включая требования технического задания и требования стандартов ИСО), преобразованных в номинальные объекты. Максимальная эффективность от использования на проекте УП может быть достигнута путём интеграции прототипа в каждый из этапов разработки.

Программная разработка с использованием УП. Модель разработки программного обеспечения с использованием управляющего прототипа (УП-разработка) порождает ряд процессов на этапах, связанных с управлением требованиями, обеспечением качества, проектированием, управлением рисками. На рис. 1 представлена модель УП-разработки в общем виде.

Первый этап УП-разработки — формирование требований — может быть представлен такими процессами, как проведение исследований в данной области, анализ, обоснование разработки, создание документации о границах проекта, формирование внутренних локальных стандартов и пр. Как правило, данный этап заканчивается созданием наглядно оформленного технического задания (ТЗ), но зачастую требования ТЗ не могут быть чётко сформулированными ввиду различных обстоятельств. По этой причине переход к разработке УП может быть начат до завершения текущего этапа. В таком случае УП выступает в качестве программного отражения сути ТЗ либо в качестве дополнения технического задания, тем самым являясь его составной частью.

Когда все требования определены, начинается этап проектирования, в рамках которого с использованием УП выявляются логические связи разрабатываемого решения, тем самым подготавливается платформа для создания тест-дизайна и выработки концепции обеспечения качества текущего проекта. Также на данном этапе может быть составлен план разработки или определена концепция планирования в процессе реализации. На этапе проектирования могут уточняться требования, предъявляемые к УП, и

модифицироваться сам УП в зависимости от особенностей необходимой инфраструктуры и иных особенностей ведения проекта.

Рис. 1. Функциональная схема реализации этапов модели УП-разработки программного

обеспечения

Этапы непосредственной реализации и тестирования принимают в качестве основного прототипа разработанный УП, который в самом начале является эталонным. В дальнейшем он должен быть модифицирован, если возможность его изменения была предусмотрена на этапах проектирования и формирования требований. Если разработанный УП является частью ТЗ и не предусмотрена его модификация в ходе разработки, тогда создаётся дубликат УП, который будет считаться основным и дополняющим эталонный прототип (ЭУП). В этом случае этап синхронизации и верификации УП с разрабатываемым ПО будет дополнен процессом верификации УП с ЭУП.

Модель УП-разработки допускает также создание шаблонного прототипа качества (УПК), реализующего требования международных стандартов качества серии ИСО. Шаблонный прототип может стать универсальным лекалом для ряда проектов, требующих выполнения определённого набора стандартов и соблюдения формальных требований, не привязанных по специфике к какому-либо одному проекту. УПК также может быть модифицированным или эталонным, при этом блок синхронизации и верификации будет расширен задачами выполнения их обработки. Максимальная эффективность от использования УПК достигается при использовании средств контроля уровня качества ПО. Возможный набор составляющих УП на проекте представлен на рис. 2.

Особое внимание заслуживают механизмы синхронизации и верификации, поскольку проблемы, выявленные на данном этапе, оказывают непосредственное влияние на следующие аспекты:

- качество конечного решения, которое напрямую зависит от соблюдения своевременно обозначенных требований;

- технические риски (риски программирования, риски тестирования) и риски требований, включая экономические, организационные и другие;

106

- зрелость организации и проекта, стабильность и уровень которых зависят от степени успешности реализации проекта в рамках запланированных сроков разработки.

Рис. 2. Составные элементы управляющего прототипа

В то же время механизмы управления качеством, зрелостью и рисками могут влиять, используя обратную связь, на организацию и проведение испытаний, а также предоставлять данные, необходимые для устранения возникающих противоречий. Успешное прохождение данного этапа позволяет переходить к непосредственному внедрению продукта с минимально возможным уровнем риска соответствия конечного решения сформированным ранее требованиям. Этап эксплуатации и сопровождения связан с верификацией УП с полученным программным продуктом, поскольку при возникновении новых требований или модификации существующих могут произойти изменения в процессах всех предшествующих этапов [2].

Апробация модели УП-разработки. С целью выявления эффективности предложенной методологии, а также особенностей реализации модели УП-разработки на практике был проведён ряд испытаний. Одновременно были созданы два параллельных проекта: «Демо-1» и «Демо-2», направленные на разработку одноимённых прикладных приложений. Общее время разработки (Вр) в рамках реализации тестовых проектов было спланировано на две итерации, при равенстве одной итерации сорока часам.

В ходе реализации проекта «Демо-1» велась разработка приложения, предназначенного для обработки математических констант локальной базы данных (БД). Методология разработки не предусматривала прототипирования и была ориентирована на временную диаграмму жизненного цикла, представленную на рис. 3.

ф ® ©

Вфт \

Вп

Вр

И

\

Вт

/

Вв

1 итерация

2 итерация

Рис. 3. Временная диаграмма жизненного цикла проекта «Демо-1»

На рис. 3 цифрой 1 обозначено событие, характеризующееся завершением этапа формирования требований (Вфт) и началом проектирования (Вп). Время формирования требований и время внедрения (Вв) для тестовых проектов являются номинальными. Поэтому с целью получения наиболее объективных данных для проектов «Демо-1» и «Демо-2» временные значения определены как равные.

Цифра 2 показывает время завершения этапа проектирования и переход к активной разработке (Вр), т.е. написанию исходного кода и реализации интерфейса пользователя.

Под цифрой 3 указано время начала тестирования (Вт), продолжающееся до конца первой итерации. С началом новой итерации возобновляются процессы фазы активной разработки, тестирование же переходит в пассивный режим. Однако через промежуток времени, равный приблизительно половине запланированного объёма активной разработки второй итерации, тестирование возобновляется и длится до момента ввода в эксплуатацию (цифра 4). Завершение второй итерации является, по сути, завершением жизненного цикла разработки «Демо-1».

В рамках реализации проекта «Демо-2» было разработано приложение для обработки физических констант облачной БД. Разработка велась в соответствии с моделью УП-разработки. Временная диаграмма жизненного цикла проекта представлена на рис. 4.

На рис. 4 цифрой 1 обозначено событие, характеризующееся завершением этапа формирования требований (Вфт) и началом тестирования (Вт). В данном случае процесс тестирования в рамках обеспечения качества ПО начинается с момента появления требований, параллельно составлению которых ведётся разработка управляющего прототипа (Вп), что позволяет тестировать завершённые элементы прототипа, а вместе с тем контролировать соответствие УП указанным требованиям. При этом разделение времени синхронизации и верификации (Всв) на объективное (перед завершением каждой итерации) и условное (обозначено на рис. 4 пунктирной линией) является важной особенностью разработки приложения «Демо-2». Условное время синхронизации и верификации по времени совпадает с диаграммой времени тестирования, поскольку процессы обеспечения качества неразрывно связаны также с контролем исполнения требований, проектных наработок и неявных требований качества разрабатываемого продукта согласно соответствующим стандартам серии ИСО.

Рис. 4. Временная диаграмма жизненного цикла проекта «Демо-2»

Цифра 2 показывает время завершения этапа прототипирования/проектирования и переход к активной разработке (Вр), т.е. написанию исходного кода и реализации интерфейса пользователя. По завершении данной фазы и до конца первой итерации запускаются процессы синхронизации/верификации (цифра 3). Аналогично процесс завершения фазы активной разработки для второй итерации сопровождается возобновлением процессов синхронизации и верификации (учитывается объективное время).

Завершение тестирования свидетельствует также и о завершении фазы синхронизации/верификации (цифра 5), что предваряет этап ввода в эксплуатацию. Завершение второй итерации является, по сути, завершением всего жизненного цикла разработки проекта «Демо-2».

В результате проведённых испытаний были выявлены следующие закономерности. Так, при разработке приложения «Демо -1» количество технических дефектов с уровнем критичности выше среднего к концу второй итерации было свыше 10%, что не может считаться приемлемым показателем надёжности продукта [1]. По этой причине количество итераций было увеличено. Как показала практика, время, затрачиваемое на процессы доработки и повторного тестирования, снижалось экспоненциально. К концу пятой итерации все критичные дефекты были устранены. С начала непосредственной реализации приложений (Вр) суммарная трудоёмкость проекта «Демо-2» превосходила трудоёмкость проекта «Демо -1» почти в полтора раза, однако с каждым следующим этапом жизненного цикла разработки она снижалась, и уже до этапа внедрения явно прослеживалось превосходство проекта с УП -разработкой более чем на 15%.

1 1

8 .00 -

□ Вфт

7 Ж 0 ^ 3 °ВП

шв

□ Вт

6 ^^^^ 4

5

а

Рис. 5. Диаграммы распределения временных ресурсов тестовых проектов:

«Демо-1» (а) и «Демо-2» (б)

Таким образом, фаза активной разработки, как наиболее трудоёмкая и превосходящая по времени (рис. 5,а), не обеспечивает ожидаемый эффект реализации проекта. Свыше 110 человеко-часов и многократные доработки приложения позволяют в очередной раз убедиться в ничтожно малой эффективности распространённых на сегодняшний день методов разработки ПО.

Обратный результат был получен при использовании управляющего прототипа. Несмотря на значительные затраты ресурсов фазы синхронизации/верификации ввод проекта в эксплуатацию был осуществлён в запланированный срок, при этом затраты на активную разработку не превысили прогнозируемый объём времени (рис. 5,б). Более того, качество продукта, разработанного в рамках проекта «Демо -2», может считаться более стабильным за счёт достижения к концу шестой итерации точки минимальных потерь, когда количество рисков и количество дефектов примерно равно, а последующие итерации могут повлечь за собой увеличение одной из функций согласно системе Лотки — Вольтерры [4].

Заключение. Применение модели УП-разработки в рамках реализации программных проектов продемонстрировало следующие преимущества:

- превосходство по времени — проект «Демо-2» был завершён в полном объёме в запланированные сроки;

- превосходство по трудоёмкости — несмотря на сравнительное повышение трудоёмкости в начале первой итерации, общая трудоёмкость разработки к концу второй итерации была значительно ниже, чем на проекте «Демо-1»;

- превосходство по качеству — отсутствие программных дефектов выше среднего уровня критичности и практически полное отсутствие технических рисков к истечению времени тестирования.

Данные приведённого эксперимента позволяют прийти к выводу, что эффективность использования УП имеет высокий потенциал. Помимо успешного распределения ресурсов на реализацию ПО, тестирование и процессы синхронизации/верификации, интеграция в процесс программной разработки всех составляющих управляющего прототипа говорит о положительном опыте применения модели. Гарантировать более вы-

сокое качество конечного продукта, а также повышение уровня зрелости, как долгосрочных проектов, так и организации в целом использование модели УП-разработки способно лишь при совпадении запланированного объёма человеко-часов с точкой минимальных потерь, что было продемонстрировано в ходе апробации модели.

ЛИТЕРАТУРА

1. Данилин А. О., Петрухнова Г. В. Формализация определения уровня качества программного обеспечения // Вестник Воронежского государственного технического университета. — 2014. — Т.10, 11. — № 5-1. — С.52—56.

2. Данилин А. О., Кол М. Д., Петрухнова Г. В. Обеспечение надёжности программных решений // Информатика: проблемы, методология, технологии: мат. XV Международной науч.-методич. конф. — Воронеж, 2015. Т.2. — С.265—268.

3. Данилин А. О. Управление техническими рисками разработки программного обеспечения // Научный вестник Воронежского государственного архитектурно-строительного университета. Серия : Информационные технологии в строительных, социальных и экономических системах. 2013. — Вып. 2/2. — С. 309—310.

REFERENCES

1. Danilin A. O., Petruhnova G. V. Formalizacija opredelenija urovnja kachestva pro-grammnogo obespechenija // Vestnik Voronezhskogo gosudarstvennogo tehnicheskogo uni-versiteta. — 2014. — T.10, 11. — № 5-1. — S.52—56.

2. Danilin A. O., Kol M. D., Petruhnova G. V. Obespechenie nadjozhnosti pro-grammnyh reshenij // Informatika: problemy, metodologija, tehnologii: mat. XV Mezhdu-narodnoj nauch.-metodich. konf. — Voronezh, 2015. T.2. — S.265—268.

3. Danilin A. O. Upravlenie tehnicheskimi riskami razrabotki programmnogo obespechenija // Nauchnyj vestnik Voronezhskogo gosudarstvennogo arhitekturno-stroitel'nogo universiteta. Serija : Informacionnye tehnologii v stroitel'nyh, social'nyh i jekonomicheskih sistemah. 2013. — Vyp. 2/2. — S. 309—310.

СВЕДЕНИЯ ОБ АВТОРЕ

Данилин Артем Олегович. Аспирант кафедры автоматизированных и вычислительных систем.

Воронежский государственный технический университет.

E-mail: pushnir@rambler.ru

Россия, 394026, г. Воронеж, Московский проспект, 14. Тел. +79103486270.

Danilin Artem Olegovich. Graduate student of the chair of Automation and Computer Systems.

Voronezh State Technical University.

Work address: Russia, 394026, Voronezh, Moskovsky Prospect, 14. Tel. (473) 234-22-39

Ключевые слова: управляющий прототип (УП); уровень качества; уровень зрелости; прототип качества; УП-разработка.

Key words: managing prototype (MP); the level of quality; maturity; prototype quality; MP-development.

УДК 005

i Надоели баннеры? Вы всегда можете отключить рекламу.