Программные продукты и системы

Одним из основных научно-технических направлений деятельности НИИ «Центрпрограм- мсистем» (г. Тверь) является разработка АСУ в защищенном исполнении. При этом под защищенным исполнением АСУ понимается наличие в ее составе организационных и программно-технических средств защиты информации от несанкционированного доступа.

Разработка автоматизированных систем выполняется, как правило, в виде опытно-конструкторских работ (ОКР) и регламентируется в основном ГОСТами 34-й серии и РВ 15.203-2001. Эти стандарты определяют перечень этапов ОКР, последовательность и порядок их выполнения, формы отчетных документов и т.п. Необходимо отметить, что приведенные ГОСТы в части, касающейся разработки ПО, являются весьма устаревшими.

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

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

Гибкие (agile) методы активно применяются в области разработки ПО в последние несколько лет. Они позволяют устранить ряд недостатков классического каскадного метода (метода водопада), заключающихся в недостаточной гибкости и формальном управлении проектами в ущерб срокам, стоимости и качеству. Недостаточная гибкость процесса разработки обусловливает неспособность реагировать на возникающие изменения требований к системе и может в конечном итоге привести к превышению бюджета, срыву сроков и невостребованности продукта. Причинами таких изменений могут быть корректировка требований по результатам демонстрации ПО заказчику, конечным пользователям или экспертам в автоматизируемой предметной области, ошибки, допущенные при формулировании требований ранее, изменения в самой предметной области и т.д. Ряд зарубежных авторов [2–4] отмечают, что изменения функциональных требований к ПО в общем случае практически неизбежны и являются частью объективной реальности, с которой следует не бороться, препятствуя появлению изменений, а наоборот, приветствовать их даже на завершающих стадиях проекта, потому как скорректированные требования являются важнейшим условием создания действительно востребованного изделия, удовлетворяющего актуальные потребности заказчика. Принятие изменений требований даже в конце разработки является одним из принципов гибкой методологии, определенных в Agile Manifesto [5].

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

Однако при управлении объемными проектами формализация имеет большую ценность, так как обеспечивает прозрачность процесса разработки. Известный американский стандарт по управлению требованиями Project Management Bo­dy of Knowledge (PMBOK) в своей третьей версии формально закреплял только методику каскадной модели, а в 2009 г. Институт управления проектами (Project Management Institute, PMI) предложил гибридную методологию, позволяющую сочетать достоинства классического метода водопада и современных гибких методов разработки.

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

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

В НИИ «Центрпрограммсистем» при выполнении ряда ОКР была предпринята попытка использовать гибкие методы в рамках действующих нормативных документов и государственных стандартов разработки систем специального назначения.

Из известных гибких методов был выбран Scrum [6]. Следование его основным принципам позволяет предоставлять конечному пользователю (заказчику) работающее ПО с новыми возможностями в фиксированные и относительно короткие итерации, называемые спринтами (sprints). При этом сбор требований, проектирование, разработка ПО и его демонстрация заказчику могут выполняться в каждом спринте. Однако в соответствии с ГОСТ РВ 15.203-2001 этапы ОКР в общем случае выполняются последовательно: этапу разработки рабочей конструкторской документации предшествуют этапы эскизного и технического проектирования, корректировка опытного образца выполняется после испытаний и т.д. Этапы выполнения ОКР зачастую длятся месяцами и даже годами. Кроме того, эффективная итерационная разработка ПО требует постоянного вовлечения экспертов в автоматизируемой предметной области в процесс разработки, а не только в моменты сдачи этапов, защиты эскизного и технического проектов и т.д. В связи с этим целесообразно сформировать группу экспертов в предметной области для обеспечения сбора требований, получения обратной связи и выполнения ряда других работ в рамках ОКР. Например, при разработке автоматизированных систем и программных комплексов военного назначения в группу экспертов могут войти должностные лица органов военного управления и специалисты организаций, выполняющих военно-научное сопровождение.

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

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

Одним из современных подходов к формированию функциональных требований является разработка вариантов использования (прецедентов) [2]. Варианты использования утверждают поведение системы при обработке запросов пользователя (основного действующего лица) и в общем случае являются простыми текстовыми описаниями последовательности взаимодействия пользователя с системой. При необходимости в описание функциональных требований можно добавить диаграммы на формальных языках типа UML, BPMN, IDEF и других, поясняющие схемы, рисунки и прочие материалы. Однако, как показывает практика и отмечают некоторые авторы изданий на тему гибкой методологии и современных методов формирования требований [2], наибольшую ценность представляют именно текстовые описания прецедентов. Разработанные варианты использования целесообразно включить в соответствующие постановки задач в раздел «Порядок решения задачи». При необходимости следует изменить способ нумерации расширений описаний прецедентов. Классическим способом нумерации расширений является добавление к порядковому номеру расширяемого шага основного сценария прецедента литер «а», «б», «в» (a, b, c) и т.д. Например, основной сценарий прецедента содержит действие «3. Система выводит документ на печать». Поведение системы в случае сбоя печати описывается в расширениях прецедента, например: «3а. В принтере нет бумаги – система предлагает добавить бумагу в лоток и повторить попытку печати». Такой способ нумерации расширений прецедентов, приведенных в постановках задач, зачастую является непривычным для экспертов в предметной области и может быть заменен на более естественную формулировку в повествовательном стиле.

Трудоемкость разработки, последующего согласования и утверждения постановок задач кардинально сокращается в случае применения гибких методов разработки ПО.

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

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

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

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

Как показала практика, таким инструментом может быть простая таблица, содержащая два столбца: в одном указываются задачи ТЗ, в другом – соответствующие им прецеденты (табл. 1). Она может быть дополнена столбцом с указанием названия соответствующей постановки или постановок задач.

Таблица 1

Простой вариант таблицы трассировки функциональных требований

Table 1

An easy case of a functional specification trace table

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

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

Значительно упростить процесс разработки функциональных требований, повысить их организацию и обеспечить соответствие формальным задачам ТЗ позволяет формирование карт воздей- ствий (Impact Mapping) [7] и карт историй (story mapping) [8].

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

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

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

Другим хорошо зарекомендовавшим себя на практике подходом к формированию функциональных требований является составление карты историй (story map). Такой подход позволяет в простой табличной форме представить сценарий применения системы и отобразить в нем место функциональных требований в виде вариантов использования или прецедентов (табл. 2).

Строка таблицы «Сценарий применения системы» описывает последовательность действий пользователей – специалиста медицинской организации и управления с использованием разрабатываемой системы. Последовательность состоит из отдельных шагов, расположенных слева направо и конкретизируемых в описаниях соответствующих прецедентов. В строке таблицы «Скелет системы» отображаются функциональные требования, реализация которых позволит сформировать скелет действующей системы. Скелетная реализация не позволяет выполнить все запланированные функциональные требования и формальные задачи ТЗ в полном объеме, но она обеспечивает выполнение прогона системы по сценарию применения от начала до конца, хотя и с ограничениями. Указание формальной задачи (или цели) вверху таблицы дает возможность упростить и визуализировать трассировку требований.

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

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

При планировании работ следует учитывать, что сбор требований и проектирование их реализации в общем случае должны опережать разработку соответствующего ПО. Это позволяет избежать простоев в работе программистов. Целесообразная длительность такого опережения составляет одну-две итерации [3] (табл. 3).

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

В первом столбце таблицы указываются функциональные требования. Их приоритет оценивается в баллах от одного до трех и указывается во втором столбце. Сложность реализации каждого функционального требования оценивается аналогично и указывается в третьем столбце таблицы. Далее приводится ссылка на прототип графического интерфейса, разработанного дизайнером (проектировщиком). Знак «+» в пятом столбце означает наличие приемочных тестов, подготовленных группой тестировщиков. Столбец «Результат тестирования» позволяет уяснить наличие и общий характер выявленных дефектов (ошибок). Например, условное обозначение «Ф(Р)», закрашенное красным цветом, означает, что ошибки были выявлены при проведении приемочных тестов вручную, а «Ф(А)» – при выполнении автоматического приемочного тестирования. Кроме того, в этом столбце можно указывать и другие условные обозначения результатов тестирования, по тем или иным причинам представляющие интерес для руководителя проекта.

Функциональные требования, запланированные к реализации в одной и той же итерации, отображаются в соседних строках таблицы. Группа требований одной итерации отчеркивается двойной линией от остальной части бэклога. Сверху указываются номер итерации, даты ее начала и окончания и версия выпуска (релиза) ПО, которое будет продемонстрировано заказчику по завершении итерации. Итерации располагаются в бэклоге проекта в хронологическом порядке сверху вниз.

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

Еще одним решением, позволяющим упростить планирование гибкой разработки, является приоритизация требований.

Некоторые зарубежные специалисты в области гибких методов [3] советуют оценивать приоритеты функциональных требований в баллах, например, от одного до трех по мере возрастания приоритета. Единых подходов к определению приоритета функциональных требований нет, приоритеты оцениваются умозрительно, исходя из личных представлений и опыта того или иного привлеченного эксперта. Применение упомянутых ранее Impact Mapping и карт историй позволяет облегчить процесс приоритизации требований за счет визулизации их влияния на достижение поставленных бизнес-целей и сценарий применения системы соответственно. Кроме того, при необходимости бизнес-цели, достижение которых обеспечивается реализацией соответствующих функциональных требований, могут быть отображены в виде вех или приведены как дополнительные описания итераций в бэклоге проекта. Аналогичным образом в бэклоге могут быть отображены формальные задачи, определенные в ТЗ на ОКР.

Метод гибкой разработки Scrum предлагает отслеживать процесс выполнения работы при помощи диаграмм сгорания задач (Burndown chart) [3]. Такая диаграмма графически отображает уже вложенные трудозатраты и трудоемкость оставшейся работы и может быть составлена на одну или несколько итераций. По мере выполнения работы кривая оставшихся трудозатрат, отображаемая на графике, будет стремиться к нулю. Однако, учитывая, что перечень функциональных требований формируется динамически, уже реализованные требования могут корректироваться заказчиком по итогам демонстрации очередной версии ПО, скорость работы команды разработчиков меняется от итерации к итерации, диаграмма сгорания задач на практике позволяет сделать лишь очень приблизительный прогноз сроков завершения работы. Ско- рее, она может быть использована для отслеживания расчетного запаздывания реализации проекта. Более точные оценки процесса разработки ПО могут быть получены при совокупном использовании бэклога, карт историй и способа Impact Mapping. При этом целесообразно сосредоточиться на достижении заранее спланированных контрольных точек, приведенных в планирующих документах.

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

Литература

1.     Фатрелл Р., Шафер Д., Шафер Л. Управление программными проектами. Достижение оптимального качества при минимуме затрат. М.: Вильямс, 2003. 1136 с.

2.     Коберн А. Современные методы описания функциональных требований к системам. М.: Лори, 2012. 263 с.

3.     Расмуссон Д. Гибкое управление IT-проектами. Как мастера Agile делают выдающееся ПО. СПб: Питер, 2012. 272 с.

4.     Кон М. Scrum: гибкая разработка ПО. М.: Вильямс, 2011. 576 c.

5.     Manifesto for Agile Software Development. URL: http://www.agilemanifesto.org (дата обращения: 20.12.2015).

6.     Сазерленд Дж. Scrum. Революционный метод управления проектами. М.: Манн, Иванов и Фербер, 2015. 288 с.

7.     Adzic G. Impact Mapping: Making a Big Impact with Software Products and Projects. Leanpub, 2014, 133 p.

8.     Patton J. User Story Mapping. Discover the Whole Story, Build the Right Product. O’Reilly Media, Inc, 2014, 278 p.