Интеграция требований Гост 34.601-90 и итерационной методики Rational Unified Process

Размещено на http://www.allbest.ru/

Интеграция требований Гост 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. Пер Кролл, Ф. Крачтен. Rational Unified Process - это легко Руководство для практиков, перевод с английского. Кудиц-образМосква 2004 432 с.

2. Е. Колтунова. Требования к информационной системе и модели жизненного цикла.

Размещено на Allbest.ru