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

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

В состав типовой АСУ входят технические средства, информационно-лингвистическое и программное обеспечение (ПО), которое разделяется на общее (ОПО) и специальное (СПО) программное обеспечение ^[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), автоматической сборки и тестирования.

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

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

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

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

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

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

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

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