Статья 'О «гибких» технологиях в разработке программного обеспечения систем поддержки принятия решений' - журнал 'Программные системы и вычислительные методы' - NotaBene.ru
по
Меню журнала
> Архив номеров > Рубрики > О журнале > Авторы > Требования к статьям > Политика издания > Редакция > Порядок рецензирования статей > Редакционный совет > Ретракция статей > Этические принципы > О журнале > Политика открытого доступа > Оплата за публикации в открытом доступе > Online First Pre-Publication > Политика авторских прав и лицензий > Политика цифрового хранения публикации > Политика идентификации статей > Политика проверки на плагиат
Журналы индексируются
Реквизиты журнала
ГЛАВНАЯ > Вернуться к содержанию
Программные системы и вычислительные методы
Правильная ссылка на статью:

О «гибких» технологиях в разработке программного обеспечения систем поддержки принятия решений

Тиханычев Олег Васильевич

ORCID: 0000-0003-4759-2931

кандидат технических наук

заместитель начальника отдела управления перспективных разработок, ГК "Техносерв"

111395, Россия, г. Москва, ул. Юности, 13

Tikhanychev Oleg Vasilyevich

PhD in Technical Science

Deputy Head of Department in the Office of Advanced Development, Technoserv Group 

111395, Russia, Moscow, Yunosti str., 13

tow65@yandex.ru
Другие публикации этого автора
 

 

DOI:

10.7256/2454-0714.2018.2.23743

Дата направления статьи в редакцию:

31-07-2017


Дата публикации:

13-06-2018


Аннотация: Предметом исследования является процесс разработки программного обеспечения автоматизированных систем управления. Объект исследования – методологии организации разработки программного обеспечения. Общепризнанное перспективное направление повышения эффективности применения организационно-технических систем - автоматизация управления ими. В первую очередь автоматизация, организуемая по принципу системы поддержки принятия решений. Существенную долю эффективности любой автоматизированной системы обеспечивает её программное обеспечение. В первую очередь это относится к прикладному или специальному программному обеспечению. Разработка таких программ сопряжена с определёнными трудностями, в первую очередь – организационного характера. Обобщённый анализ показал, что в мировой практике существует достаточно широкий спектр методов организации процесса разработки программ. Эти методы можно разделить на две крупные группы относительно используемых алгоритмов на «жесткие» и «гибкие». Каждый из подходов эффективен для тех или иных условий разработки программного обеспечения. В статье проведён анализ факторов, влияющих на эффективность применения той или иной методологии, синтезированы предложения по целесообразности использования различных методологий в разных условиях процесса разработки. Анализ показал, что для условий разработки прикладного программного обеспечения автоматизированных систем поддержки принятия решений наибольшую эффективность обеспечивает применение «гибких» подходов. В обзорной статье рассмотрены особенности методологии Scrum, являющейся примером типичной реализации «гибких» подходов. На основе анализа особенностей применяемых методов и требований к их реализации, впервые сформулированы выводы о целесообразности применения гибких технологий при разработке прикладного программного обеспечения автоматизированных систем поддержки принятия решений


Ключевые слова:

автоматизация управления, поддержка принятия решений, автоматизированные системы управления, программное обеспечение, технологии разработки программ, СППР, организация процесса разработки, гибкие технологии разработки, технология Agile, метод разработки Scrum

УДК:

004.415.2

Abstract: The subject of the study is the process of developing software for automated control systems. Object of research - methodologies for organizing software development. Automation of management is a universally recognized promising direction of increasing the efficiency of the application of complex technical systems. First of all, automation, organized by the principle of decision support systems. The basis of the effectiveness of any automated system is its software. First of all, this applies to application software. The development of such programs entails certain difficulties, primarily organizational ones. Generalized analysis has shown that in the world practice there is a rather wide range of methods for organizing the development of programs. These methods can be divided into two large groups with respect to the algorithms used for "hard" and "flexible" ones. Each of the approaches is effective for certain conditions of work. The article analyzes the factors influencing the effectiveness of applying a particular methodology, synthesizes suggestions on the appropriateness of using different methodologies in different conditions of the development process. The analysis showed that for the development of automated decision support systems, the use of "flexible" approaches is most effective. In the article features of Scrum technology are considered, as a typical implementation of "flexible" methodologies. Conclusions about the expediency of its application in the development of application software for automated decision support systems are formulated


Keywords:

control automation, decision support, automated systems, software, software development technologies, DMSS, development process organization, flexible technologies, Agile technology, Scrum development method

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

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

Разработка любой АСУ, в том числе и её программных компонентов, осуществляется по ряду этапов, определяемых нормативной технической документацией (НТД) по организации процессов разработки. В соответствии с ГОСТ, к этим этапам относятся [2]:

- формирование требований к АСУ;

- разработка концепции АСУ;

- разработка и утверждение технического задания на создание АСУ;

- разработка эскизного проекта;

- разработка технического проекта;

- разработка рабочей конструкторской документации;

- ввод системы в действие;

- сопровождение АСУ.

Содержание данных этапов и их последовательность определяет технологию разработки и программных компонентов автоматизированных СППР [3].

На практике, при реализации указанного порядка возникает множество проблем, в первую очередь – организационных. Это определяется тем, что в разработке автоматизированных систем управления сложными распределёнными системами участвует не одно предприятие, а взаимозависимая кооперация разработчиков, работающих в интересах собственных групп потребителей, а иногда и нескольких заказчиков. Ситуация осложняется тем, что в большинстве случаев разработчикам не ставится сразу конкретная задача, а требования к системе постоянно уточняются: на этапах эскизного и технического проектирования.

Очевидное решение проблемы – использование средств автоматизации организации процесса разработки. Но проблема не так проста, как кажется: в настоящее время имеется достаточно широкий спектр подобных средств, реализующих различные методологии разработки. И выбор конкретного средства, определяющего в конечном итоге эффективность разработки, завязанную на сроки, стоимость и качество конечного продукта, является нетривиальной задачей, требующей скорейшего разрешения.

2.Анализ существующих технологий организации разработки программного обеспечения

Безотносительно используемой нашими разработчиками НТД, в мировой практике существует достаточно широкий спектр технологий разработки ПО. К основным из них можно отнести: рациональное программирование RUP (Rational Unified Process), итеративно-инкрементальный метод OpenUP, технологии быстрой разработки приложений RAD (rapid application development), методология MSF (Microsoft Solutions Framework), методология разработки программ с сертифицируемым уровнем надёжности Cleanroom (Cleanroom Software Engineering), технологии гибкого программирования Agile и другие.

Каждая из перечисленных технологий имеет преимущества и недостатки в тех или иных условиях применения, которые, в свою очередь, задаются НТД.

Анализ практики разработки программ показывает, что большинство из перечисленных технологий ориентированы на «жесткие» методологии, реализующие строгие алгоритмы работы. Подходы, определяемые существующей НТД, также рассчитаны на «жесткую» методологию, когда уже на начальном этапе работы в деталях определяется облик будущей системы: её назначение, структура, связи. Это в полной мере относится к разработке программного обеспечения.

Применение такого подхода оправдано с экономической точки зрения. Он хоть и не является самым эффективным из возможных, но обеспечивает получение «минимального гарантированного» результата. А в условиях, когда на начальном этапе удаётся описать детальную функциональную и информационную модель автоматизируемого процесса, показывает достаточно высокий уровень эффективности [4,5,6].

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

3.Рекомендации по выбору методологии для разработки программного обеспечения

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

Целесообразность использования того или иного подхода к разработке ПО определяется условиями данного процесса. Эти условия, в свою очередь, определяются: типом разрабатываемого ПО, порядком финансирования процесса разработки и способом управления разработкой.

Ориентируясь на тип разрабатываемого ПО необходимо, в первую очередь, учитывать порядок разработки и влияние вносимых изменений на другие компоненты АСУ. Например, СПО, в большинстве случаев, разрабатывается в завершающей стадии проекта, при уже готовом ОПО и ОСПО и практически не влияет на другие компоненты АСУ. Любые изменения ОПО, напротив, существенны для всех остальных компонентов и т.п. Ещё один показатель из этой группы: наличие или отсутствие прототипа. ОПО и ОСПО разрабатываются, как правило, по аналогии с ранее разработанными средствами аналогичного назначения и процесс их разработки может выстраиваться в соответствии с уже известной этапностью разработки прототипа. В свою очередь, СПО, как правило, разрабатывается без прототипа, на основе тенденций, и использование "жестких" подходов в данном случае может быть проблематичным.

Относительно способа управления разработкой можно выделить: формат задания порядка и содержания работ, порядок выстраивания отношений между заказчиком и исполнителем и другое. Каждый из этих факторов оказывает влияние на предпочтительность использования тех или иных технологий разработки ПО: чем жестче они регламентированы, тем проблематичнее использование "гибких" подходов.

С точки зрения финансирования проекты можно классифицировать как по «модели цены», выбираемой в ходе задания разработки, так и относительно этапности оплаты. Наименования моделей цены: от "жесткой фиксированной" до группы "по фактическим затратам" уже позволяют сделать предварительные выводы о возможности использования методологии разработки ПО.

Таким образом, сопоставление комплекса требований по разработке классов ПО АСУ и возможностей по детальности задания работ позволяет сделать выводы относительно целесообразности использования «жестких» или «гибких» технологий. Вариант обобщения таких выводов относительно основных классов ПО АСУ приведен в таблице 1.

Таблица 1 – Целесообразность применения «гибких» технологий при разработке ПО СППР

Условия задания разработки

Класс программного обеспечения

ОПО

ОСПО

СПО

Детальное описание структуры и требований

-

-

±

Общее описание требований без детализации структуры

-

±

±

Общее описание назначения, без детализации структуры

±

±

+

± - в зависимости от порядка финансирования проекта.

Анализ содержания таблицы 1 позволяет сформировать выводы, что для проектов разработки ПО с фиксированными требованиями целесообразно использовать «жесткие» технологии, а для проектов, отличающихся высоким уровнем неопределённости – «гибкие».

К одной из основных методологий, реализующих «гибкий» подход, относят методологию Аgile (Agile software development). Эта методология реализуется несколькими методиками [7,8], такими как экстремальное программирование (XP), методология разработки динамических систем (Dynamic Systems Development Method - DSDM), функционально-ориентированная разработка (Feature driven development - FDD), Scrum.

4.О возможности использования методологии Scrum для организации разработки программного обеспечения СППР

Типичный представитель семейства «гибких» подходов, методология Scrum, реализующая набор принципов, позволяющих по фиксированным и небольшим по времени итерациям, называемым спринтами (sprints), предоставлять конечному пользователю версии работающего ПО с непрерывно нарастающим функционалом.

Реализация этой методологии [9,10] осуществляется командами разработчиков, включающих основные группы специалистов (Core roles):

- руководитель разработки (Product Owner), который является, по сути, связующим звеном между командой разработки и заказчиком, представляя интересы конечного пользователя;

- координатор проекта (Scrum master), управляющий и организующий процесс разработки;

- команда разработчиков (Development team), состоящая из специалистов, непосредственно разрабатывающих программную продукцию: программных инженеров, архитекторов, программистов, тестировщиков и т.п.

Реализующая методологию Scrum команда разработчиков должна обладать следующими обязательными качествами:

- быть самоорганизующейся;

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

- нести коллективную ответственность за выполняемую работу.

К разработке проекта могут дополнительно привлекаться группы «сторонних» участников (Ancillary roles): конечные пользователи продукта (Users), эксперты в предметной области (Consulting Experts) и ряд других специалистов.

Основой методологии Scrum является цикличность работы, этапы (Sprint), в течении которых выполняется работа над очередной версией продукта. Важным условием является то, что по окончанию каждого этапа должна быть получена очередная рабочая версия продукта. Sprint ограничены по времени и имеют одинаковую продолжительность.

На начальном этапе выполнения проекта определяется его обобщённая структура и сроки, формируется журнал разработки (Project Backlog), содержащий перечень требований по функциональности конечного продукта, описанный в виде набора работ, упорядоченных по степени важности. Журнал может редактироваться всеми участниками скрам-процесса в соответствии с их правами доступа.

Для контроля выполнения проекта используется специализированный инструмент: так называемая «диаграмма сгорания задач» (Burndown chart). Диаграмма визуализирует соотношение выполненных и оставшихся работ относительно общего времени на разработку проекта.

Перед началом каждого этапа проводится задающее совещание (Sprint Planning), на котором производится оценка и формирование перечня работ (Sprint Backlog) в журнале Project Backlog. Sprint Backlog содержит конкретные задачи, которые должны быть выполнены в рамках текущего этапа.

В рамках методологии, в ходе выполнения каждого этапа, проводятся ежедневные совещания (Daily Scrum), с задачей определения состояния работы над текущим Sprint, выявление проблем, уточнение стратегии достижения целей этапа.

По окончании каждого этапа проводится подведение его итогов (Sprint Review) и ретроспективное совещание (Retrospective meeting), задача которых оценить производительность работы на прошедшем этапе, спрогнозировать ожидаемую эффективность в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ в заданные сроки и другие вопросы.

К положительным сторонам методологии Scrum можно отнести то, что она позволяет получить потенциально рабочий продукт в конце каждого этапа. Scrum ориентирован на требования заказчика, адаптивен к их корректировке по мере разработки проекта. Фиксированная небольшая длительность каждого спринта придаёт процессу разработки предсказуемость и гибкость. Работа группы разработчиков осуществляется на основе самоорганизации с минимальной координацией руководством. Именно принципы открытости, инспекции и адаптации, реализованные в Scrum, делают применение гибких технологий привлекательным для заказчика проекта, в первую очередь – финансового. В том числе, в условиях высоких рисков, определяющих ожидаемую результативность работ по созданию СПО СППР. Исходя из этого, «гибкие» подходы оказываются наиболее удобными и для разработчиков при работе над уникальными проектами, к которым можно отнести большинство проектов разработки СПО автоматизированных систем управления [11,12].

К недостаткам методологии Scrum можно отнести высокие требования к качеству команды разработчиков, которым может соответствовать далеко не каждый коллектив.

Конечно, Scrum – это только методология, хоть и реализующая известную философию непрерывного совершенствования рабочего процесса через каждую его составляющую "Кайдзен" (Kaizen), давно доказавшую свою эффективность. Для её практического применения необходимо наличие технологического средства, в данном конкретном случае – программы для реализации методов управления проектами. Специализированного инструментария такого типа существует достаточно много: Jira, Gemini, Redmine, Team Foundation Server (TFS) и другие. Функции этих программ во многом похожи, часть их совместима друг с другом.

Личный опыт автора – использование программы TFS [13] для организации процесса создания программных компонентов СППР коллективом разработчиков. Практика показала, что возможности данной программы позволяют достаточно просто формировать «спринты» и задавать их содержание по иерархии «ситуации» - «функции» - «задачи», эффективно распределять и перераспределять работы, контролировать их выполнение. Наличие возможностей коллективной работы, фиксации ошибок и локализации «препятствий», обеспечивает распределённое управление и самоорганизацию команды разработчиков. Встроенный инструментарий управления разработкой делает TFS практически идеальным инструментом для реализации «гибких» методологий разработки ПО, обеспечивающим весь цикл, от назначения работ (рисунок 1), до контроля их выполнения (рисунок 2), автоматической сборки и тестирования. _1new_01

Рисунок 1.Форма задания работы и назначения исполнителя

Рисунок 2. Форма сквозного контроля работ в TFS

Одновременно, использование TFS не противоречит сложившимся требованиям НТД, позволяя включать в описание работ постановки задач, алгоритмы, электронные модели в нотациях IDEF, прототипы интерфейсов и другие данные в виде прикреплённых файлов. Впрочем, как отмечалось ранее, TFS не единственная система, эффективно работающая с "гибкими" технологиями. Эту сферу активно автоматизируют и другие разработчики. Например, в продукте JIRA создано специальное приложение JIRA Agile (рисунок 3). _3_01

Рисунок 3.Главная форма проекта JIRA Agile Scrum

Впрочем, вне зависимости от положительных сторон и недостатков, использование тех или иных методологий и технологий в каждом конкретном случае, определяется назначением разрабатываемого продукта и условиями разработки.

5.О перспективах применения «гибких» технологий при разработке программного обеспечения СППР

Как показал анализ предметной области, в ряде случаев, характеризуемых неопределённостью условий разработки, применение «гибких» методологий, и таких инструментов как Scrum, позволит существенно повысить эффективность процесса: как в части функционала разрабатываемого продукта, с точки зрения заказчика по существу, так и с точки зрения эффективности затрат, то есть оптимизации участия финансового заказчика.

К сожалению, существующие, определяемые НТД подходы нацелены исключительно на «жесткие» методологии. А назначение и область применения СППР определяет, в том числе, необходимость использования «гибких» подходов к созданию ПО для них. Реализация мер по внедрению «гибких» технологий разработки в область создания ПО СППР, где высока творческая составляющая и имеется априорная неопределённость результата, является непростой задачей, но необходимые усилия окупятся с избытком за счёт повышения эффективности всех этапов процесса разработки.

Библиография
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Ссылка на эту статью

Просто выделите и скопируйте ссылку на эту статью в буфер обмена. Вы можете также попробовать найти похожие статьи


Другие сайты издательства:
Официальный сайт издательства NotaBene / Aurora Group s.r.o.