Рус Eng За 365 дней одобрено статей: 1896,   статей на доработке: 303 отклонено статей: 796 
Библиотека
Статьи и журналы | Тарифы | Оплата | Ваш профиль

Вернуться к содержанию

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

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

старший научный сотрудник, ЗАО "НИИ проблем управления, информатизации и моделирования АВН"

123007, Россия, г. Москва, пр-д Хорошевский 1-Й, 5

Tikhanychev Oleg Vasilyevich

PhD in Technical Science

Senior Researcher, "Research Institute for Control, Informatization and Modeling of AVN"

123007, Russia, g. Moscow, pr-d Khoroshevskii 1-I, 5

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

 

Аннотация.

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

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

УДК:

004.415.2

DOI:

10.7256/2454-0714.2018.2.23743

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

05-12-2017


Дата рецензирования:

25-12-2017


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

13-06-2018


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:

development process organization, DMSS, software development technologies, software, automated systems, decision support, control automation, 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.
ГОСТ 34.003-90 Автоматизированные системы. Термины и определения. – Введ. 01.01.92.-М.: Госстандарт России, 1992.-12 с. (Государственный стандарт Российской Федерации).
2.
ГОСТ 34.601-90 Автоматизированные системы. Стадии создания-Введ. 01.01.92.-М.: Госстандарт России, 1992.-7 с. (Государственный стандарт Российской Федерации).
3.
ГОСТ 19.102-77 Единая система программной документации. Стадии разработки программ-Введ. 1.01.80.-М.: Государственный комитет стандартов Совмина СССР, 1987.-6 с. (Государственный стандарт Российской Федерации).
4.
Рекомендации по стандартизации Р 50.1.028-2001 "Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования" (приняты постановлением Госстандарта РФ от 2 июля 2001 г. №256-ст) – М.: ИПК «Издательство стандартов», 2001.
5.
Тиханычев О.В., Саяпин О.В., Гахов В.Р. Современные технологии информационного обследования как фактор успеха автоматизации управления // Информатизация и связь. – 2013. - №6, - с.90-93.
6.
Лукинова О.В. Методологические аспекты управления жизненным циклом информационной системы на основе инструментов функциональной стандартизации // Программные продукты и системы. 2016. - № 4. - с.27–35. DOI:10.15827/0236-235X.116.027-035
7.
Хенрик Книберг. Scrum и XP: заметки с передовой - Scrum and XP from the trenches.-C4Media, 2007. — С. 140. — ISBN 978-1-4303-2264-1.
8.
Майк Кон. Scrum: гибкая разработка ПО - Succeeding with Agile: Software Development Using Scrum. — М.: «Вильямс», 2011. — С. 576.
9.
Джефф Сазерленд. Scrum. Революционный метод управления проектами-Scrum. The art of doing twice the work in half the time. — Манн, Иванов и Фербер, 2016.-288 с.
10.
Кеннет Рубин. Основы Scrum: Практическое руководство по гибкой разработке ПО = Essential Scrum: A Practical Guide to the Most Popular Agile Process. — М.: «Вильямс», 2016. – 544 с.
11.
Тиханычев О.В. Общие подходы к обеспечению автоматизированной поддержки принятия решений. – М.: Эдитус, 2014. – 64 с. ISBN 978-5-00058-060-8
12.
Симанков В.С., Толкачев Д.М. Информационное обеспечение ситуационного центра с использованием сети Интернет // Программные системы и вычислительные методы. — 2015.- № 3.-С.267-272. DOI: 10.7256/2454-0714.2015.3.16979
13.
Тиханычев О.В., Макарцев Л.В., Гахов В.Р. Рациональная организация процесса разработки прикладного программного обеспечения как предпосылка успешной автоматизации поддержки принятия решений // Программные продукты и системы. – 2017. - №4. С.706-710. DOI: 10.15827/0236-235X.120.706-710
References (transliterated)
1.
GOST 34.003-90 Avtomatizirovannye sistemy. Terminy i opredeleniya. – Vved. 01.01.92.-M.: Gosstandart Rossii, 1992.-12 s. (Gosudarstvennyi standart Rossiiskoi Federatsii).
2.
GOST 34.601-90 Avtomatizirovannye sistemy. Stadii sozdaniya-Vved. 01.01.92.-M.: Gosstandart Rossii, 1992.-7 s. (Gosudarstvennyi standart Rossiiskoi Federatsii).
3.
GOST 19.102-77 Edinaya sistema programmnoi dokumentatsii. Stadii razrabotki programm-Vved. 1.01.80.-M.: Gosudarstvennyi komitet standartov Sovmina SSSR, 1987.-6 s. (Gosudarstvennyi standart Rossiiskoi Federatsii).
4.
Rekomendatsii po standartizatsii R 50.1.028-2001 "Informatsionnye tekhnologii podderzhki zhiznennogo tsikla produktsii. Metodologiya funktsional'nogo modelirovaniya" (prinyaty postanovleniem Gosstandarta RF ot 2 iyulya 2001 g. №256-st) – M.: IPK «Izdatel'stvo standartov», 2001.
5.
Tikhanychev O.V., Sayapin O.V., Gakhov V.R. Sovremennye tekhnologii informatsionnogo obsledovaniya kak faktor uspekha avtomatizatsii upravleniya // Informatizatsiya i svyaz'. – 2013. - №6, - s.90-93.
6.
Lukinova O.V. Metodologicheskie aspekty upravleniya zhiznennym tsiklom informatsionnoi sistemy na osnove instrumentov funktsional'noi standartizatsii // Programmnye produkty i sistemy. 2016. - № 4. - s.27–35. DOI:10.15827/0236-235X.116.027-035
7.
Khenrik Kniberg. Scrum i XP: zametki s peredovoi - Scrum and XP from the trenches.-C4Media, 2007. — S. 140. — ISBN 978-1-4303-2264-1.
8.
Maik Kon. Scrum: gibkaya razrabotka PO - Succeeding with Agile: Software Development Using Scrum. — M.: «Vil'yams», 2011. — S. 576.
9.
Dzheff Sazerlend. Scrum. Revolyutsionnyi metod upravleniya proektami-Scrum. The art of doing twice the work in half the time. — Mann, Ivanov i Ferber, 2016.-288 s.
10.
Kennet Rubin. Osnovy Scrum: Prakticheskoe rukovodstvo po gibkoi razrabotke PO = Essential Scrum: A Practical Guide to the Most Popular Agile Process. — M.: «Vil'yams», 2016. – 544 s.
11.
Tikhanychev O.V. Obshchie podkhody k obespecheniyu avtomatizirovannoi podderzhki prinyatiya reshenii. – M.: Editus, 2014. – 64 s. ISBN 978-5-00058-060-8
12.
Simankov V.S., Tolkachev D.M. Informatsionnoe obespechenie situatsionnogo tsentra s ispol'zovaniem seti Internet // Programmnye sistemy i vychislitel'nye metody. — 2015.- № 3.-S.267-272. DOI: 10.7256/2454-0714.2015.3.16979
13.
Tikhanychev O.V., Makartsev L.V., Gakhov V.R. Ratsional'naya organizatsiya protsessa razrabotki prikladnogo programmnogo obespecheniya kak predposylka uspeshnoi avtomatizatsii podderzhki prinyatiya reshenii // Programmnye produkty i sistemy. – 2017. - №4. S.706-710. DOI: 10.15827/0236-235X.120.706-710