"", 6, 2008 .

ИНТЕГРАЦИЯ ТРЕБОВАНИЙ ГОСТ 34.601-90 И ИТЕРАЦИОННОЙ МЕТОДИКИ RATIONAL UNIFIED PROCESS

Бородин Е.В., Селезнев К.А., Гулидов Д.Н.
(Московский государственный институт электронной техники)

Отечественные информационные стандарты не учитывают особенности создания сложного программного обеспечения, в результате чего IT-компании вынуждены адаптировать требования ГОСТов под новые задачи.
В статье представлена функционально-итерационная модель жизненного цикла разработки социально-ориентированной информационной системы «Одно окно» на ос­нове интеграции требований ГОСТ 34.601-90 и методики Rational Unified Process (RUP).

Постановка задачи

 

В Москве в рамках реализации Городской целевой программы «Электронная Москва» проводятся работы по реализации режима «Одного окна» во взаимоотноше­ниях граждан, органов исполнительной власти и городских организаций.
Одним из пунктов программы является информационная поддержка реформы  муниципальных органов по работе с гражданами и хозяйствующими субъектами в ре­жиме «Одного окна».
Информационная поддержка режима «Одного окна» означает создание соци­ально – ориентированной информационной системы, что в свою очередь подразумевает разработку программного обеспечения и реализацию целого ряда организационных ме­роприятий по созданию и развитию нормативно-правовой базы, регулирующей взаи­моотношения создателей, владельцев, операторов и пользователей информационных ресурсов и систем.
Проблема разработки информационной системы «Одно окно» заключается в том, что существующие отече­ственные методики создания программных средств будучи жестко регламентиро­ванными ГОСТами 19-й и 34-й серий и более новым ГОСТ Р ИСО МЭК 12207 ориен­тированы на «водопадную» модель разработки программного обеспечения, представ­ленную на рис. 1.

Рис. 1 . «Водопадная» модель жизненного цикла информационной системы

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

Поскольку разработка в соответствии с упомянутыми ГОСТами проводится по этапам этой модели, то и недостатками следования этим стандартам является:

Получается, что процесс разработки информационных систем для нужд государственных организаций должен соответствовать требованиям ГОСТов, не отве­чающих современным реалиям. Выходом из данной ситуации является интеграция тре­бований отечественных стандартов, необходимых для сдачи продукта заказчику, и не­официальных стандартов, де-факто регламентирующих процесс создания программ­ного средства с учетом современных тенденций. В результате интеграции должна быть создана модель жизненного цикла информационной системы, отвечающая требованиям ГОСТ 34.601-90 и новых методик, позволяющих устранить недостатки «водопадной» модели.

Представление разработки программного обеспечения в терми­нах итераций RUP

Общая характеристика

 

На сегодняшний день наиболее востребованными оказались методики так на­зываемого «итеративного наращивания функциональности», при использовании кото­рых проект разбивается на несколько итераций, включающих все типы проектных ра­бот. Результатом каждой итерации является работающая система, реализующая опре­деленные функциональные требования и представляющая ценность для заказчика, как самостоятельный продукт.
Функционально-итерационное наращивание системы обладает следующими преимуществами:

На сегодняшний день наиболее совершенной итеративной методикой явля­ется RUP. RUP сложный, детально проработанный, итеративный, архитектурно-ориенти­рованный процесс разработки программного обеспечения [1].
Жизненный цикл RUP разбивается на однотипные итерации, которые группи­руются в четыре основные фазы [2], в каждой из которых выполняются девять процес­сов, составляющих две группы (Рис. 2):

Процессы первой группы:

Процессы второй группы:

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


Рис. 2 . Схема RUP по стадиям работы над проектом

На рис. 2 представлена схема процессов RUP. Горизонтальное измерение пред­ставляет собой динамичную структуру временного измерения процесса, выраженного в форме фаз и итераций, где «высота потока» показывает его интенсивность.
Вертикальное измерение группирует по итерациям прикладные элементы про­цесса – работы, приложения, документы [3].
Простой перенос западной практики в российские условия не даст желаемых результатов. Помимо того, что внедрение методики RUP связано с издержками на подготовку высококвалифицированных специалистов, она характеризуется и явными недостатками.

Недостатки RUP

Действительно, деятельность RUP начинается со стадии сбора и формулирова­ния требований к системе, минуя этап обследования и описания предметной области, к которому относятся следующие процедуры:

Создание программного обеспечения без этапа обследования предметной об­ласти является оправданным только при разработке небольших информационных сис­тем, чего нельзя сказать о построении социально – ориентированной системы город­ского масштаба, которая затрагивает интересы широких слоев населения, бизнеса и го­сударственного аппарата.
На практике перечисленные процедуры часто даже не предшествуют, а лежат в параллельных плоскостях со стадиями жизненного цикла информационной системы.
Методика RUP предоставляет возможность для документирования только части из перечисленных процедур, поскольку ориентируются в значительной степени на разработку программных систем.
Деятельность RUP сразу начинается с моделирования процессов «как должно быть» (планируемое состояние процесса) посредством определения вариантов использования (часть функциональности сис­темы, необходимая для получения пользователем значимого, ощутимого и измеримого для него результата) на диаграмме прецедентов (Рис. 3)

Рис. 3 . Диаграмма прецедентов

и последующей детализации конкретного варианта на диаграмме активности (Рис. 4).

Рис. 4 . Диаграмма активности

Другим недостатком RUP является то, что он имеет дело с системой целиком, а не ее функциональными частями [3], в результате чего отсутствует возможность компонентного построения системы. RUP ориентирован на поддержку всего жизненного цикла программного продукта без учета модульности, начиная со стадии сбора и фор­мулирования требований к системе, проектирования и заканчивая стадиями сопровож­дения, т.е. без возможности возвратов «как бы» в начало проекта после завершения и ввода в эксплуатацию первой части системы.
Построение же «больших» систем, к которым, безусловно, относятся социально-ориентированные программные комплексы, осуществляется с использованием прагматических принци­пов работы со сложными системами, одним из которых является принцип модульности.
Модульность, как принцип организации больших систем в виде наборов подсис­тем, предписывает организовывать сложную систему в виде набора более простых мо­дулей, взаимодействующих друг с другом через четко определенные интерфейсы. При этом каждая задача, решаемая всей системой, разбивается на более простые подзадачи отдельных модулей, результат выполнения которых, скомбинированный определенным образом, дает в итоге решение исходной задачи.
Модульный подход позволяет ускорить создание системы, выполняя разработку подсистем параллельно, и по мере готовности модулей производить их интеграцию в единую систему. Данный подход отвечает и принципам адаптивности разработки, ко­торая заключаются в том, что первоначальные требования со временем меняются и при проектировании системы необходимо управлять данными изменения.
Из этого можно сделать вывод, что новая модель жизненного цикла информационной системы должна учитывать пре­имущества итеративного наращивания функциональности, а также быть достаточно простой в применении, как для заказчика, так и для исполнителей.

Предлагаемое решение

Новая модель представляет собой интеграцию этапов ГОСТ 34. 601-90, которые включают объем работ, требуемых заказчиком, с методикой RUP, которая организует выполнение этих работ в возвратно-поступательном стиле. Такую функ­ционально – итеративную организацию жизненного цикла проекта по разработке ин­формационной системы «Одно окно» можно представить следующим образом (Рис. 5).


Рис. 5 . Модель жизненного цикла информационной системы на основе интеграции требований ГОСТ 34.601-90 и методики RUP.

Как видно из рис. 5, представленный жизненный цикл состоит из этапов разра­ботки каждого функционального модуля системы «Одно окно». Состав этапов соответ­ствует ГОСТ 34.601-90, но в отличие от требований стандарта, на каждом этапе выпол­няются семь процессов: шесть процессов из второй группы и, отсутствующий в RUP, этап обследования предметной области. Процессы первой группы на рис. 5 не представ­лены, так как их анализ в данной статье не проводится.
Параллельное выполнение семи процессов позволяет на каждом этапе жизнен­ного цикла осуществлять корректировку ранее выявленных требований к системе и учитывать вновь появившиеся. Например, на этапе №7 «Тестовая эксплуатация» пред­полагается устранение замечаний пользователей. Эта деятельность подразумевает оп­ределенные действия, связанные с анализом, проектированием и программированием, то есть на этапе №7 выполняются все процессы разработки.
«Волнами» на рисунке представлена активность каждого процесса. Так, в начале итерации большее внимание уделяется обследованию и моделированию предметной области, а в конце тестированию и интеграции модуля системы.
Заключительными этапами представленного жизненного цикла являются этапы №7-9. На основании результатов, достигнутых к одному из этих этапов, появляется возможность параллельно приступить к реализации очередного модуля системы, так как уже к этапу № 7 интенсивность основных проектных работ уменьшается, и проект­ные ресурсы высвобождаются. Также по результатам первой итерации может быть принято решение о приостановки проекта, что в результате не будет означать закрытие проекта, так как к концу первой итерации часть функционала системы создана и вне­дрена.
При реализации проекта с использованием функционального – итеративного жизненного цикла основная задача проекта разбивается на подзадачи, решаемые парал­лельным наложением процессов. Каждый этап приводит к определенным результатам. В частности, он дает возможность уточнить постановку задачи и перечень процессов, которые целесообразно активизировать. В конце каждого этапа подводятся локальные итоги, анализируются результаты, корректируются при необходимости планы следую­щего этапа и инициируется переход к работам следующей итерации.

Выводы

 

Использование функционально – итерационного жизненного цикла при создании социально-ориентированной информационной системы позволяет:

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

Используемая литература

 

  1. W. W. Royce. Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, pp. 1–9, August 1970
  2. Philippe Kruchten, Going Over the Waterfall with the RUP.
  3. Пер Кролл, Ф. Крачтен. Rational Unified Process – это легко Руководство для практиков, перевод с английского. Кудиц-образМосква 2004 432 с.
  4. Е. Колтунова. Требования к информационной системе и модели жизненного цикла.

 

"", 6, 2008 .