CC BY
252
УДК 004.413 Дата подачи статьи: 25.12.15
DOI: 10.15827/0236-235X.113.005-012
ОСОБЕННОСТИ ПРИМЕНЕНИЯ СОВРЕМЕННЫХ МЕТОДОВ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ЗАЩИЩЕННЫХ АВТОМАТИЗИРОВАННЫХ СИСТЕМ
В.В. Карпов, к.т.н.., первый зам. генерального директора, [email protected]; А.В. Карпов, к.т.н., зав. отделением, [email protected] (НИИ «Центрпрограммсистем», просп. 50 лет Октября, 3а, г. Тверь, 170024, Россия)
Разработка ПО защищенных автоматизированных систем регламентируется рядом нормативных актов и государственных стандартов. Однако за время, прошедшее с даты ввода их в действие, технология разработки ПО ушла далеко вперед. В частности, классическая каскадная модель разработки ПО, которая исправно служила разработчикам многие годы, в последнее время признана неэффективной из-за недостаточной гибкости в угоду формальному управлению разработкой. Недостаточная гибкость процесса разработки обусловливает неспособность реагировать на возникающие изменения требований к системе и может привести к невыполнению технического задания. Организация гибридного метода разработки, сочетающего достоинства классического подхода и современных гибких методов, может разрешить возникшее противоречие между высоким технологическим уровнем разработки современных АСУ и устаревшими требованиями руководящих документов. Комбинированные модели разработки, полученные путем интеграции современных гибких методов проектирования на этапах каскадной модели жизненного цикла разработки ПО, представляют большой интерес как с научной точки зрения - для совершенствования методических подходов к разработке ПО, так и с практической - для получения качественного ПО, соответствующего заданным в техническом задании требованиям.
В статье рассмотрены некоторые особенности внедрения гибких методов разработки функционального ПО специального назначения, выявленные специалистами НИИ «Центрпрограммсистем» при выполнении ряда опытно-конструкторских работ. К ним относятся формирование требований и управление ими, включая трассировку и приорити-зацию, планирование и отслеживание процесса выполнения работы. Рассмотрен ряд отличий этих видов деятельности при разработке ПО специального назначения, выполняемых в соответствии с действующими государственными стандартами и классическим каскадным методом разработки. Предложены решения, позволяющие организовать гибридный процесс, сочетающий достоинства каскадного и гибкого методов разработки функционального ПО специального назначения и обеспечивающий соответствие действующим государственным стандартам выполнения ОКР.
Ключевые слова: гибкие методы, гибридный метод, agile, Scrum, разработка ПО.
Одним из основных научно-технических направлений деятельности НИИ «Центрпрограммсистем» (г. Тверь) является разработка АСУ в защищенном исполнении. При этом под защищенным исполнением АСУ понимается наличие в ее составе организационных и программно-технических средств защиты информации от несанкционированного доступа.
Разработка автоматизированных систем выполняется, как правило, в виде опытно-конструкторских работ (ОКР) и регламентируется в основном ГОСТами 34-й серии и РВ 15.203-2001. Эти стандарты определяют перечень этапов ОКР, последовательность и порядок их выполнения, формы отчетных документов и т.п. Необходимо отметить, что приведенные ГОСТы в части, касающейся разработки ПО, являются весьма устаревшими.
Действительно, за десятилетия, прошедшие с даты ввода их в действие, технология разработки ПО ушла далеко вперед. Так, классическая каскадная модель разработки ПО в последнее время признана неэффективной из-за недостаточной гибкости в угоду формальному управлению разработкой [1]. Недостаточная гибкость процесса разработки обусловливает неспособность реагировать на изменения требований к системе и может в конечном итоге привести к невыполнению технического задания (ТЗ). В связи с этим возникает про-
тиворечие между технологическим уровнем разработки современных АСУ и устаревшими требованиями руководящих документов.
Разрешение указанного противоречия возможно путем интеграции современных гибких методов проектирования на этапах каскадной модели жизненного цикла разработки ПО. Полученные таким образом комбинированные модели представляют большой интерес и с научной точки зрения -для совершенствования методических подходов к разработке ПО, и с практической - для получения качественного ПО, соответствующего заданным требованиям.
Гибкие (agile) методы активно применяются в области разработки ПО в последние несколько лет. Они позволяют устранить ряд недостатков классического каскадного метода (метода водопада), заключающихся в недостаточной гибкости и формальном управлении проектами в ущерб срокам, стоимости и качеству. Недостаточная гибкость процесса разработки обусловливает неспособность реагировать на возникающие изменения требований к системе и может в конечном итоге привести к превышению бюджета, срыву сроков и невостребованности продукта. Причинами таких изменений могут быть корректировка требований по результатам демонстрации ПО заказчику, конечным пользователям или экспертам в автоматизируемой
предметной области, ошибки, допущенные при формулировании требований ранее, изменения в самой предметной области и т.д. Ряд зарубежных авторов [2-4] отмечают, что изменения функциональных требований к ПО в общем случае практически неизбежны и являются частью объективной реальности, с которой следует не бороться, препятствуя появлению изменений, а наоборот, приветствовать их даже на завершающих стадиях проекта, потому как скорректированные требования являются важнейшим условием создания действительно востребованного изделия, удовлетворяющего актуальные потребности заказчика. Принятие изменений требований даже в конце разработки является одним из принципов гибкой методологии, определенных в Agile Manifesto [5].
Внедрение гибких методов разработки ПО обеспечивает постепенную итерационную реализацию проекта с постоянной обратной связью от конечного пользователя. Проект развивается небольшими итерациями, в рамках каждой из которых в общем случае реализуется относительно небольшое приращение функционала системы, представляющее ценность для пользователя. Каждая итерация заканчивается выпуском новой версии ПО, которая демонстрируется пользователю (заказчику) с целью получения обратной связи. Объем программного кода, разработанного в рамках очередной итерации, оказывается относительно небольшим, что обеспечивает возможность его корректировки в рамках текущего проекта в случае вероятных изменений функциональных требований. В результате необходимые изменения вносятся в программный код своевременно.
Однако при управлении объемными проектами формализация имеет большую ценность, так как обеспечивает прозрачность процесса разработки. Известный американский стандарт по управлению требованиями Project Management Body of Knowledge (PMBOK) в своей третьей версии формально закреплял только методику каскадной модели, а в 2009 г. Институт управления проектами (Project Management Institute, PMI) предложил гибридную методологию, позволяющую сочетать достоинства классического метода водопада и современных гибких методов разработки.
Учитывая положительный мировой опыт использования гибких методов, задача их внедрения в области разработки систем специального назначения представляется актуальной.
Внедрение гибких методов в разработку ПО является комплексной и достаточно трудоемкой задачей. Она связана с изменением основных технологических и организационных процессов разработки ПО, способа взаимодействия с заказчиком, планирования и контроля разработки и т.д. Итерационная разработка задает новый ритм работы не только коллективу разработчиков, но и другим отделам организации и даже ее руководству. Нередко
для внедрения гибких методов разработки в организацию приглашаются сертифицированные и дорогостоящие специалисты.
В НИИ «Центрпрограммсистем» при выполнении ряда ОКР была предпринята попытка использовать гибкие методы в рамках действующих нормативных документов и государственных стандартов разработки систем специального назначения.
Из известных гибких методов был выбран Scrum [6]. Следование его основным принципам позволяет предоставлять конечному пользователю (заказчику) работающее ПО с новыми возможностями в фиксированные и относительно короткие итерации, называемые спринтами (sprints). При этом сбор требований, проектирование, разработка ПО и его демонстрация заказчику могут выполняться в каждом спринте. Однако в соответствии с ГОСТ РВ 15.203-2001 этапы ОКР в общем случае выполняются последовательно: этапу разработки рабочей конструкторской документации предшествуют этапы эскизного и технического проектирования, корректировка опытного образца выполняется после испытаний и т.д. Этапы выполнения ОКР зачастую длятся месяцами и даже годами. Кроме того, эффективная итерационная разработка ПО требует постоянного вовлечения экспертов в автоматизируемой предметной области в процесс разработки, а не только в моменты сдачи этапов, защиты эскизного и технического проектов и т.д. В связи с этим целесообразно сформировать группу экспертов в предметной области для обеспечения сбора требований, получения обратной связи и выполнения ряда других работ в рамках ОКР. Например, при разработке автоматизированных систем и программных комплексов военного назначения в группу экспертов могут войти должностные лица органов военного управления и специалисты организаций, выполняющих военно-научное сопровождение.
Важными аспектами внедрения гибких методов являются сбор и управление требованиями. Гибкая методология разработки ориентируется на динамическое формирование требований. Это дает заказчику право и возможность по результатам очередной итерации формулировать новые требования. Однако такой порядок формирования требований может привести к тому, что вновь сформированные требования будут противоречить уже реализованным и в некоторых случаях требовать решений, нарушающих архитектуру разработанного ранее ПО. Кроме того, динамическое формирование требований усложняет процесс управления ими, снижает предсказуемость процесса разработки и затрудняет планирование работы. Динамическое формирование требований может означать изменение объема работы, сроков проекта или его стоимости. Однако ОКР, как правило, выполняются по заранее согласованному и утвержденному ТЗ, а сроки и стоимость работы зачастую жестко опреде-
ляются контрактными документами. При этом четко заданный в ТЗ перечень задач, решение которых должно обеспечить разрабатываемое ПО, ограничивает возможность изменения объема работы.
Способом управления объемом работы по реализации функциональных требований, предъявляемых к ПО специального назначения, является разработка постановок задач. Постановки задач позволяют конкретизировать и детализировать требования, описать порядок их реализации (порядок решения задач), используемые алгоритмы, форматы данных, определить формы входных и выходных документов и пр. Уточнение и конкретизация функциональных требований в постановках задач фактически позволяют варьировать трудоемкость выполнения задач ТЗ, а утверждение их заказчиком обеспечивает им юридическую силу.
Одним из современных подходов к формированию функциональных требований является разработка вариантов использования (прецедентов) [2]. Варианты использования утверждают поведение системы при обработке запросов пользователя (основного действующего лица) и в общем случае являются простыми текстовыми описаниями последовательности взаимодействия пользователя с системой. При необходимости в описание функциональных требований можно добавить диаграммы на формальных языках типа UML, BPMN, IDEF и других, поясняющие схемы, рисунки и прочие материалы. Однако, как показывает практика и отмечают некоторые авторы изданий на тему гибкой методологии и современных методов формирования требований [2], наибольшую ценность представляют именно текстовые описания прецедентов. Разработанные варианты использования целесообразно включить в соответствующие постановки задач в раздел «Порядок решения задачи». При необходимости следует изменить способ нумерации расширений описаний прецедентов. Классическим способом нумерации расширений является добавление к порядковому номеру расширяемого шага основного сценария прецедента литер «а», «б», «в»
Ь, ^ и т.д. Например, основной сценарий прецедента содержит действие «3. Система выводит документ на печать». Поведение системы в случае сбоя печати описывается в расширениях прецедента, например: «3 а. В принтере нет бумаги - система предлагает добавить бумагу в лоток и повторить попытку печати». Такой способ нумерации расширений прецедентов, приведенных в постановках задач, зачастую является непривычным для экспертов в предметной области и может быть заменен на более естественную формулировку в повествовательном стиле.
Трудоемкость разработки, последующего согласования и утверждения постановок задач кардинально сокращается в случае применения гибких методов разработки ПО.
При «классическом» выполнении ОКР постановки задач разрабатываются и утверждаются до начала непосредственной разработки ПО. Это зачастую затягивает разработку постановок и приводит к их «раздуванию», спровоцированному перепроектированием, обусловленным стремлением экспертов в предметной области включить в постановки задач побольше требований «на всякий случай». Однако по ходу развития проекта большая часть подобных требований может потерять свою актуальность, потребовать существенной корректировки, выйти за границы системы или вовсе оказаться надуманной.
В случае итерационного подхода актуальность сформулированных функциональных требований и корректность их реализации может быть определена в конце каждой итерации по результатам демонстрации разработанного ПО группе экспертов в предметной области. При этом трудоемкость разработки постановок задач, их согласования и утверждения заказчиком сокращается. Это происходит прежде всего потому, что постановки задач содержат уже реализованные функциональные требования. К моменту согласования постановок эксперты в предметной области и конечные пользователи уже имели возможность апробировать на практике реализацию сформулированных в них требований. В случае изменений требований постановки задач могут быть скорректированы и утверждены повторно даже на этапе разработки рабочей конструкторской документации и более поздних.
Наличие формально заданных в ТЗ функциональных требований к ПО, с одной стороны, и требований, определенных в виде описания прецедентов, с другой, обусловливают актуальность задачи обеспечения их трассировки и непротиворечивости. Разработанные описания прецедентов не должны противоречить формальным требованиям ТЗ. Напротив, они должны их уточнять, детализировать и конкретизировать. Кроме того, неэффективная трассировка требований в сочетании с недостаточным планированием ближе к завершению этапа разработки рабочей конструкторской документации может привести к авральной реализации формальных задач с низким приоритетом, отложенных «на потом».
Учитывая это, представляется целесообразной реализация дополнительного инструмента, позволяющего отслеживать соответствие реализуемых функциональных требований (прецедентов) формальным задачам, сформулированным в ТЗ. Это обеспечит трассировку требований и их непротиворечивость.
Как показала практика, таким инструментом может быть простая таблица, содержащая два столбца: в одном указываются задачи ТЗ, в другом - соответствующие им прецеденты (табл. 1). Она может быть дополнена столбцом с указанием
Обеспечить оперативность формирования и представление сведений по движению пациентов в медицинских организациях
Специал ист медицинского ^управления
^-ч
Повысить оперативность сбора и расчетов по движению пациентов в подчиненных медицинских организациях
Обеспечить автоматизированный контроль данных от подчиненных медицинских ^организаций__j
Повысить оперативность представления сведений о движении пациентов
' Сбор данных от подчиненных ^медицинских организаций
'Расчет динамики движения пациентов в медицинских организациях
/Формирование шаблонов сводок для подчиненных медицинских организаций
^Валидация принимаемых сводок
Г Контроль приема сводок
Заполнение сводок^ Суточный учет па циентов ^
Фрагмент схемы, разработанной с использованием Impact Mapping
., .... I...
Л f.
названия соответствующей постановки или постановок задач.
Таблица 1
Простой вариант таблицы трассировки функциональных требований
Table 1
An easy case of a functional specification trace table
Такая таблица обеспечивает трассировку требований от формальных задач, определенных в ТЗ, через соответствующие постановки к конкретным описаниям прецедентов. Трассировка позволяет «не забыть» про формальные требования ТЗ, увлекшись динамическим формированием бэклога проекта по результатам работы с экспертами в предметной области.
Указание постановки задач в таблице трассировки может быть особенно актуально в случае, когда на одну задачу из ТЗ разрабатываются две и более постановок. Оформление такой таблицы, за исключением столбца с перечнем прецедентов в виде формального документа, согласование и утверждение его у заказчика существенно упрощают задачу проверки реализации требований к математическому обеспечению на этапах испытаний опытного образца конечного изделия.
Значительно упростить процесс разработки функциональных требований, повысить их организацию и обеспечить соответствие формальным задачам ТЗ позволяет формирование карт воздей-
ствий (Impact Mapping) [7] и карт историй (story mapping) [8].
Impact Mapping рассматривает функциональные требования в контексте бизнес-целей и делает акцент на тех изменениях деятельности конечных пользователей, которые должна обеспечить система для их достижения. Фрагмент упрощенной карты воздействий приведен на рисунке.
Как видно из рисунка, основной целью автоматизации является обеспечение оперативности формирования и представления сведений по движению пациентов в медицинских организациях. Эта цель может быть достигнута изменением деятельности двух специалистов: специалиста медицинского управления и специалиста медицинской организации. Изменение деятельности первого заключается в повышении оперативности сбора данных и расчетов по движению пациентов в подчиненных медицинских организациях, а также в обеспечении автоматизированного контроля получаемых данных. Повышение оперативности сбора данных и расчетов может быть обеспечено за счет автоматизированного сбора данных от подчиненных медицинских организаций и автоматизации расчета динамики движения пациентов. Аналогичным образом можно интерпретировать всю карту воздействий.
Выстраивание логической цепочки от целей через пользователей системы до конкретных функциональных требований, описываемых в виде пользовательских историй, прецедентов или вариантов использования, обеспечивает визуализацию решения актуальной задачи их трассировки.
Другим хорошо зарекомендовавшим себя на практике подходом к формированию функциональных требований является составление карты
Номер задачи ТЗ Номер постановки задачи Прецеденты
1 1.1, 1.2 1, 2, 5
2 2.1, 2.2 2, 3, 4
Таблица 2
Упрощенный пример карты историй
Table 2
A simplified example of of a strory map
Расчет сведений по движению пациентов в медицинских организациях
Специалист медицинской организации Специалист медицинского управления
Сценарий применения системы:
выполняю суточный учет движения пациентов формирую сводку по движению пациентов высылаю сводку в медицинское управление принимаю сводки от медицинских организаций выполняю расчет динамики движения пациентов в медицинских организациях и т.д.
Скелет системы:
учет пациентов только с ОРВИ только с ОРВИ в виде файла на отчуждаемом носителе по одной, с отчуждаемого носителя расчет показателя 1
.. .и с пневмонией .и с пневмонией При помощи системы обмена электронными сообщениями Сразу нескольких, с отчуждаемого носителя расчет показателя 2
...и с ожогами .и с ожогами Из системы обмена электронными сообщениями и т.д.
историй (story map). Такой подход позволяет в простой табличной форме представить сценарий применения системы и отобразить в нем место функциональных требований в виде вариантов использования или прецедентов (табл. 2).
Строка таблицы «Сценарий применения системы» описывает последовательность действий пользователей - специалиста медицинской организации и управления с использованием разрабатываемой системы. Последовательность состоит из отдельных шагов, расположенных слева направо и конкретизируемых в описаниях соответствующих прецедентов. В строке таблицы «Скелет системы» отображаются функциональные требования, реализация которых позволит сформировать скелет действующей системы. Скелетная реализация не позволяет выполнить все запланированные функциональные требования и формальные задачи ТЗ в полном объеме, но она обеспечивает выполнение прогона системы по сценарию применения от начала до конца, хотя и с ограничениями. Указание формальной задачи (или цели) вверху таблицы дает возможность упростить и визуализировать трассировку требований.
Следующими важными аспектами разработки ПО специального назначения являются планирование и отслеживание выполнения работы. Одним из недостатков гибких методов является недостаточная формализация планирования, снижающая предсказуемость выполнения проекта, в то время как действующие стандарты выполнения ОКР, напротив, предписывают разрабатывать планирующие документы, например, единый сквозной план создания изделия, сетевой план-график и т.д.
Помимо формальных требований стандартов, эксперты в предметной области и их руководство зачастую требуют разработки и согласования планирующих документов с целью организации своей деятельности.
Упростить задачу планирования гибкой разработки позволяет небольшая фиксированная длительность итераций. Следуя принципам метода Scrum, к реализации в каждом новом спринте выбираются функциональные возможности, для которых определен наибольший приоритет. Требования для реализации в очередном спринте выбираются в его начале и в общем случае не меняются до его завершения. При этом фиксированная длительность спринта обеспечивает ему некоторую предсказуемость и упрощает процесс планирования.
При планировании работ следует учитывать, что сбор требований и проектирование их реализации в общем случае должны опережать разработку соответствующего ПО. Это позволяет избежать простоев в работе программистов. Целесообразная длительность такого опережения составляет одну-две итерации [3] (табл. 3).
С целью поддержки планирования разработки ПО специального назначения, помимо формальных планирующих документов, предусмотренных действующими государственными стандартами, может быть применен адаптированный вариант бэклога проекта, предусмотренного методом Scrum (табл. 4).
В первом столбце таблицы указываются функциональные требования. Их приоритет оценивается в баллах от одного до трех и указывается во втором столбце. Сложность реализации каждого
Таблица 3
Деятельность аналитиков и проектировщиков опережает работу программистов на одну-две итерации
Table 3
Analysts' and design engineers' activity outpaces programmers' activity by one or two iterations
Роль Итерация 1 Итерация 2 Итерация 3 Итерация Z
Аналитик Сбор требований и данных от заказчика для итерации 3 Сбор требований и данных от заказчика для итерации 4 Сбор требований и данных от заказчика для итерации 5
Проектировщик Проектирование реализации требований для итерации 2 Проектирование реализации требований для итерации 3 Проектирование реализации требований для итерации 4
Программист Реализация требований итерации 1 Реализация требований итерации 2 Реализация требований итерации 3
Таблица 4
Адаптированный бэклог проекта
Table 4
An adapted project backlog
Функциональ- Приоритет Слож- Наличие прото- Готовность Наличие Результат Примечание
ное требование (прецедент) (1-3) ность (1-3) типа и ссылка на него к тестированию приемочного теста тестирования
Итерация 1 (дата начала -дата окончания) Версия 0.1
Требование 1. 1 1 1 + + Ф(Р) Группа разработчиков | Те-стировщик
Требование 2.3 1 1 + + Ф(Р) | Ф(А)
Требование 4.3 2 2 + + Ф(Р)
Требование 4.5 3 5 + + Ф(Р)
Итерация 2 (дата начала -дата окончания) Версия 0.2
Требование 1.2 1 1 + + Ф(Р) Группа разработчиков | Те-стировщик
Требование 2.2 2 3 + + Ф(Р) | Ф(А)
Требование 2.4 3 4 + + КВ
Требование 3.1 3 5 + + КВ
Требования,
не вошедшие
в итерации
функционального требования оценивается аналогично и указывается в третьем столбце таблицы. Далее приводится ссылка на прототип графического интерфейса, разработанного дизайнером (проектировщиком). Знак «+» в пятом столбце означает наличие приемочных тестов, подготовленных группой тестировщиков. Столбец «Результат тестирования» позволяет уяснить наличие и общий характер выявленных дефектов (ошибок). Например, условное обозначение «Ф(Р)», закрашенное красным цветом, означает, что ошибки были выявлены при проведении приемочных тестов вручную, а «Ф(А)» - при выполнении автоматического приемочного тестирования. Кроме того, в этом столбце можно указывать и другие условные обозначения результатов тестирования, по тем или
иным причинам представляющие интерес для руководителя проекта.
Функциональные требования, запланированные к реализации в одной и той же итерации, отображаются в соседних строках таблицы. Группа требований одной итерации отчеркивается двойной линией от остальной части бэклога. Сверху указываются номер итерации, даты ее начала и окончания и версия выпуска (релиза) ПО, которое будет продемонстрировано заказчику по завершении итерации. Итерации располагаются в бэклоге проекта в хронологическом порядке сверху вниз.
Приведенная реализация бэклога проекта не просто содержит перечень функциональных требований, но и позволяет планировать их выполнение и отслеживать результаты. Бэклог проекта обоб-
щенно отображает результаты работы системных аналитиков, программистов и тестировщиков. Непротиворечивость используемого бэклога проекта формальным планирующим документам обеспечивается за счет учета и отображения в нем формальных сроков этапов и работ выполняемой ОКР.
Еще одним решением, позволяющим упростить планирование гибкой разработки, является приори-тизация требований.
Некоторые зарубежные специалисты в области гибких методов [3] советуют оценивать приоритеты функциональных требований в баллах, например, от одного до трех по мере возрастания приоритета. Единых подходов к определению приоритета функциональных требований нет, приоритеты оцениваются умозрительно, исходя из личных представлений и опыта того или иного привлеченного эксперта. Применение упомянутых ранее Impact Mapping и карт историй позволяет облегчить процесс приоритизации требований за счет визули-зации их влияния на достижение поставленных бизнес-целей и сценарий применения системы соответственно. Кроме того, при необходимости бизнес-цели, достижение которых обеспечивается реализацией соответствующих функциональных требований, могут быть отображены в виде вех или приведены как дополнительные описания итераций в бэклоге проекта. Аналогичным образом в бэклоге могут быть отображены формальные задачи, определенные в ТЗ на ОКР.
Метод гибкой разработки Scrum предлагает отслеживать процесс выполнения работы при помощи диаграмм сгорания задач (Burndown chart) [3]. Такая диаграмма графически отображает уже вложенные трудозатраты и трудоемкость оставшейся работы и может быть составлена на одну или несколько итераций. По мере выполнения работы кривая оставшихся трудозатрат, отображаемая на графике, будет стремиться к нулю. Однако, учитывая, что перечень функциональных требований формируется динамически, уже реализованные требования могут корректироваться заказчиком по итогам демонстрации очередной версии ПО, скорость работы команды разработчиков меняется от итерации к итерации, диаграмма сгорания задач на практике позволяет сделать лишь очень приблизительный прогноз сроков завершения работы. Ско-
рее, она может быть использована для отслеживания расчетного запаздывания реализации проекта. Более точные оценки процесса разработки ПО могут быть получены при совокупном использовании бэклога, карт историй и способа Impact Mapping. При этом целесообразно сосредоточиться на достижении заранее спланированных контрольных точек, приведенных в планирующих документах.
Внедрение гибких методов в процесс разработки ПО специального назначения, безусловно, является трудоемким и обладает множеством особенностей, не рассмотренных в данной статье. Однако ряд положительных результатов, полученных НИИ «Центрпрограммсистем» при сочетании гибких методов разработки ПО с классической каскадной моделью выполнения ОКР в специальных областях, позволяет сделать вывод о возможности и актуальности применения принципов гибкой методологии в рамках действующих нормативных документов и государственных стандартов. Способы применения гибких методов, рассмотренные в данной статье, представляют собой решения, позволяющие организовать процесс разработки ПО, сочетающий преимущества современных гибких методов и классической каскадной модели жизненного цикла ПО. Гибридный процесс разработки способствует разрешению противоречия между технологическим уровнем разработки современных АСУ и устаревшими требованиями руководящих документов.
Литература
1. Фатрелл Р., Шафер Д., Шафер Л. Управление программными проектами. Достижение оптимального качества при минимуме затрат. М.: Вильямс, 2003. 1136 с.
2. Коберн А. Современные методы описания функциональных требований к системам. М.: Лори, 2012. 263 с.
3. Расмуссон Д. Гибкое управление IT-проектами. Как мастера Agile делают выдающееся ПО. СПб: Питер, 2012. 272 с.
4. Кон М. Scrum: гибкая разработка ПО. М.: Вильямс, 2011. 576 с.
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.
DOI: 10.15827/0236-235X.113.005-012 Received 25.12.15
MODERN SOFTWARE DEVELOPMENT METHODS FOR SECURED AUTOMATED SYSTEMS
Karpov V.V., Ph.D. (Engineering), 1st Deputy Director General, [email protected]; Karpov A. V., Ph.D. (Engineering), Branch Manager, [email protected] (R&D Institute Centerprogramsystem, 50 let Oktyabrya Ave. 3a, Tver, 170024, Russian Federation) Abstract. Regulations and state standards are the main documents for regulating development of secured software automated systems. However, it has been a while since their adoption, and a software development technology is upgrading fast. In particular, the classical software development waterfall model, which was taken as a basis for these state standards and had
been popular for many years, is recently found to be ineffective due to the lack of flexibility in formal development management. Lack of a development process flexibility leads to an inability to respond to emerging changes of system requirements and may lead to nonfulfillment of requirements specifications. The hybrid development method that combines the advantages of classical approach and modern flexible methods can solve the contradiction between a high technological level of modern automated systems development and outdated requirements of governing documents. The integration of modern flexible design techniques led to appearing of combination development models. At the stages of a waterfall model of software development life cycle they are of great interest both from the scientific point of view (to improve methodological approaches to software development), and practical (for high-quality software that corresponds to the requirements).
The article describes some features of introduction of flexible development methods of special purpose functional software. They were identified by the experts of the Research Institute Centerprogramsystem when working on development projects. These features include requirements formation and management including tracing and prioritization, planning and tracking a work progress. The authors consider a number of differences between these types of activities in the development of special purpose software executed in accordance with state standards and a classic waterfall development method. They suggest solutions for organizing a hybrid process that combines the advantages of waterfall and flexible methods of special purposes functional software development and ensures an appropriate implementation according to government standards.
Keywords: flexible methods, hybrid method, agile, Scrum, Centerprogramsystem, software development.
References
1. Futrell R.T., Shafer D.F., Shafer L.I. Quality Software Project Management. Prentice Hall Publ., 2002, 1680. (Russ. ed.: Moscow, Vilyams Publ., 2003, 1136 p.).
2. Cockburn A. Writing Effective Use Cases. Addison-Wesley Prof. Publ., 2000, 304 p. (Russ. ed.: Moscow, Lori Publ., 2012, 263 p.)
3. Rasmusson J. The Agile Samurai: How Agile Masters Deliver Great Software. 2010, 264 p. (Russ. ed.: St. Petersburg, Piter Publ., 2012, 272 p.).
4. Cohn M. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley Prof. Publ., 2009, 504 p. (Russ. ed.: Moscow, Vilyams Publ., 2011, 576 p.).
5. Manifesto for Agile Software Development. Available at: http://www.agilemanifesto.org (accessed December 20, 2015).
6. Sutherland J. The power of Scrum. CreateSpace Independent Publ. Platform, 2011, 128 p. (Russ. ed.: Moscow, Mann. Ivanov i Faber Publ., 2015, 288 p.).
7. Adzic G. Impact Mapping: Making a Big Impact with Software Products and Projects. Leanpub Publ., 2014, 133 p.
8. Patton J. User Story Mapping. Discover the Whole Story, Build the Right Product. O'Reilly Media, Inc., 2014, 278 p.
НИИ «Центрпрограммсистем»
Полный комплекс работ по защите государственной тайны:
- аттестационные испытания на соответствие требованиям безопасности с выдачей аттестата соответствия;
- специальные проверки для выявления технических средств перехвата информации (закладных устройств);
- специальные исследования для выявления возможных каналов утечки информации посредством побочных электромагнитных излучений и наводок.
Наши преимущества:
- крупнейшая ГГ-компания с 45-летней историей;
- более чем 20-летний опыт работы в области защиты информации;
- собственная лаборатория, отвечающая всем нормативным требованиям;
- наличие всех необходимых сертификатов и лицензий;
- современная контрольно-измерительная аппаратура, включая сертифицированные ФСТЭК России автоматизированные комплексы.
Подробности на сайте www.cpstver.ru Телефон в Москве: (495) 998-59-77 Телефон в Твери: (4822) 69-06-23
