ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.11.2023
Просмотров: 932
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Литература к главе 4
1.
IBM
Rational
RequisitePro, http://www.interface.ru/home.asp?artId=311 2.
IEEE Standard Glossary of Software Engineering Terminology, http://www.andaim.ru/computer_engineering/10363-1132.html
3.
RuGost
-
Разработка документации по
ГОСТ, http://www.rugost.com/
4.
Байкин А., Новичков А. Пять уровней зрелости требований http://www.ibm.com/developerworks/ru/library/r- requirements/index.html#autor1 5.
Боэм Б.У. Инженерное проектирование программного обеспе- чения: Пер. с англ. – М.: Радио и связь. 1985. – 512 с.
6.
Брукс Ф.П. Как проектируются и создаются программные ком- плексы. (Мифический человекомесяц). Пер. с англ. – М.: Наука 1970 7.
Буч Г., Рамбо Д., Якобсон И. Язык UML, Руководство пользова- теля. 2-е изд.: Пер. с англ. мухин Н. – М.: ДМК Пресс, 2007. – 496 с.
8.
Вали У., Лейбович Л., Превост Э. и др. Управление бизнес- процессами: от моделирования до мониторинга с использованием про- дуктов WebSphere V6.: Пер. с англ. ibm.com/redbooks 2007. – 423 c.
186 9.
ГОСТ
Р
ИСО
9000
ГОСТ
Р
ИСО
9000http://urvista.ru/certification/sert-info/sert-stand/iso-9000-standard- series/iso-9000-standard/?_openstat=ZGlyZWN0LnlhbmRle-
C5ydTs0MzAwODg2OzUwNjAzNTU2O3lhbmRleC5ydTpwcmVtaXVt
10. Кватрани Т., Палистрает Д. Визуальное моделирование с помо- щью IBM Rational Software Architect и UML. Пер. с англ. – М.: КУДИЦ-
ПРЕСС. – 2007. – 192 с.
11. Майерс Г. Надежность программного обеспечения: Пер. с англ.
– М .: Мир, 1980. – 360 с.
12. Назаров С.В. Операционные системы специализированных вы- числительных комплексов: теория построения и системного проектиро- вания. – М.: Машиностроение, 1989. – 400 с.
13. Назаров С.В. Проектирование архитектуры программных сис- тем. Разработка, анализ и управление требованиями. Сборник научных трудов по материалам международной научно-практической конферен- ции «Перспективные инновации в науке. Образовании, производстве и транспорте ’2010», том 3 Технические науки. – Одесса: Черноморье,
2010. с. 27 – 42 14. Назаров С.В. Сложность программной системы. Сборник науч- ных трудов по материалам международной научно-практической кон- ференции «Современные направления теоретических и прикладных ис- следований ‘2011», том 2 Технические науки. – Одесса: Черноморье,
2011. с. 58 – 65 15. Новичков А. Роль процесса Управления Требованиями при раз- работке сложных программных систем. Практика применения методо- логии IBM RUP и инструмента IBM Rational RequisitePro, http://www.cmcons.com/articles/upravlenie_trebovanijami-
_instrument_ibm_rational_r/
16. Новичков А., Карабанова Б. Моделирование бизнес-процессов автоматизируемой предметной области при помощи диаграмм деятель- ности
(Activity diagram) с использованием
RSA, http://www.ibm.com/developerworks/ru/library/r-rsa/index.html
17. Полис Г., Огастин Л., Лоу К., Мадхар Д. Разработка программ- ных проектов на основе Rational Unnified Process (RUP). – М.: ООО
«Бином-Пресс», 2009. – 256 с.
18. Тавассоли Д. Управление требованиями. Десять шагов на пути к совершенству, http://www.swd.ru/files/pdf/IBM_uspeh_edit1.pdf
19. Терехов А.Н. Технология программирования: Учебное пособие/
А.Н. Терехов. – М.: Университет информационных технологий; БИ-
НОМ. Лаборатория знаний. 2006. – 148 с.
20. Уровни требований к программному обеспечению http://www.atis.ru/DocItem.aspx?groupId_10=8&itemId_10=15 21. Фасбиндер М. Новые возможности версии WebSphere Business
Modeler
V6.2. http://www.ibm.com/developerworks/ru/library/wes-
0812_fasbinder4/#author1 22. Шураков В.В. Надежность программного обеспечения систем обработки данных: Учебник для вузов. – М.: Статистика, 1981. – 216 с
187
Глава 5
РАЗРАБОТКА ПРЕДВАРИТЕЛЬНОГО ВНЕШНЕГО
ПРОЕКТА
5.1. Представление и анализ требований
5.1.1. Требования в V-модели Халла
Жизненно важная часть проектирования любых систем – это разра- ботка требований, которая, в первую очередь, определяет саму про- блемную область, а затем последовательно соотносит все последующие технические решения с конкретными проблемами из этой предметной области [29]. Требования являются основой для любого проекта. Они определяют те потребности заинтересованных сторон – пользователей, потребителей, поставщиков, разработчиков и самого бизнеса – которые являются для них необходимыми, а также тот функционал, которым система должна впоследствии обладать, чтобы удовлетворить эти по- требности.
Как отмечалось выше, чтобы стать всем понятными, требования в большинстве случаев пишутся на обычном языке, что привносит про- блемы другого рода: необходимость полностью и однозначно обозна- чить проблемы и зафиксировать потребности без использования про- фессионального жаргона или предварительных договоренностей. Это весьма сложная задача. Только согласованные требования могут быть основой для проекта, однако с течением времени у заинтересованных сторон может становиться все больше и больше требований, причем интересы сторон могут вступать в конфликт между собой. Кроме того, потребности могут быть нечетко выражены в начале проекта, их удов- летворение может быть ограничено факторами, лежащими в неконтро- лируемой области, на удовлетворение потребностей могут влиять дру- гие цели проекта, которые, в свою очередь, тоже могут меняться с тече- нием времени. Согласованные требования обеспечивают базу для пла- нирования разработки системы и ее приемки по завершении работ.
Можно ли дать оценку влияния предполагаемого изменения без де- тальной проработки модели системы? С другой стороны, что будет, ес- ли отменить ранее внесенные изменения? Даже если проблема и ее ре- шение определены, необходимо оценить риски, которые могут привести к провалу проекта. Организация работы с требованиями позволяет управлять рисками на самых ранних стадиях разработки. Например, если риск, вытекающий из определенного требования, может быть от- слежен, может быть проведена оценка его влияния, вероятность появле- ния, и, как следствие, может быть разработан предварительный план по предотвращению и устранению последствий этого риска.
Таким образом, требования являются базой для планирования проек- та, управления рисками, приемочного тестирования, установления ком- промиссов (согласований) и управления изменениями.
188
Анализ требований включает [2]: обнаружение и разрешение конфликтов между требованиями; определение границ задачи, решаемой создаваемым программным обеспечением; в общем случае - определение границ и содержания программного проекта; детализацию системных требований для установления программных требований.
В SWEBOK [2] отмечается, что традиционный взгляд на анализ тре- бований часто сфокусирован или уменьшен до вопросов концептуаль- ного моделирования с использованием соответствующих аналитических методов, одним из которых является SADT – Structured Analysis and
Design Technique (методология структурного анализа и техники проек- тирования), известный по нотациям IDEF0 (функциональное моделиро- вание – стандарт IEEE 1320.1), IDEF1X (информационное моделирова- ние – стандарт IEEE 1320.2, известный также как IDEFObject), часто применяемым как для моделирования бизнес-процессов, так и структур данных, в частности – реляционных баз данных.
Не следует считать, что разработка требований – это единичная фаза, которая выполняется в начале разработки продукта. Очевидно, что тре- бования, разработанные в начале проекта, так или иначе, используются на его самом последнем этапе (рис. 5.1). Классическая V-модель [29], описывающая различные стадии проекта, в основном базируется на свя- зи между требованиями и их тестированием.
Рис. 5.1. Классическая V-модель Халла
V-модель отображает также системную разработку в терминах уров- ней, где каждый уровень соотносится с определенным этапом разработ- ки. Несмотря на то, что на каждом уровне могут использоваться не- сколько различных процессов, основной принцип работы с требования- ми не меняется. Требования могут выступать также в роли связи между
189 проектами. Это хорошая идея, по мнению Халла [29], потому что орга- низации-разработчики желают: максимально увеличить использование наработок в разных проек- тах; управлять семействами сходных продуктов; использовать программное управление для согласования действий; оптимизировать разработку, используя опыт предыдущих проектов.
Хороший набор пользовательских требований может обеспечить краткое и не техническое описание того, что будет разработано, на уровне, который доступен для понимания руководством. Аналогичным образом, системные требования могут представлять собой прекрасное техническое описание проекта. Эти два шага служат основой для всех последующих действий в рамках проекта.
Поскольку требования играют такую важную роль в разработке сис- тем, с ними нужно постоянно работать. При внесении изменения необ- ходимо в основном выполнить следующие действия: принять или отклонить изменение; согласовать стоимость изменения с заказчиками (поставщиками); организовать работы по переделке.
Основной концепцией, позволяющей проводить анализ влияний та- кого рода, является возможность установления и последующего контро- ля связей между требованиями. Можно утверждать, что управление из- менениями является важной частью работы с требованиями. Способ- ность руководителя управлять проектом в значительной степени зави- сит от качества поставленного процесса работы с требованиями.
5.1.2. Моделирование в определении требований и спецификаций
Важно понимать взаимосвязь между разработкой требований и сис- темным моделированием. Употребление термина моделирование требо- ваний неверно по сути [5]. Моделируется реализация системы, а не тре- бования к ней. Моделирование поддерживает наиболее творческий про- цесс – разработку реализации системы, выработку конкретных систем- ных решений.
Системное моделирование вносит дополнительную формальность в процессы анализа и проектирования. При разработке любой системы часто используются схемы и рисунки, которые помогают наглядно ото- бразить некоторые аспекты разработки. Системное моделирование формализует это наглядное представление не только с помощью диа- грамм, выполненных с использованием стандартных нотаций (синтак- сиса), но и обеспечивает среду (средства) для понимания и обсуждения идей, связанных с процессом разработки [29].
Искусство моделирования, по мнению многих известных ученых и инженеров, является самой творческой частью работы системного раз- работчика. В большинстве случаев модели представляют собой некий визуальный ряд, в котором для отображения информации используются взаимосвязанные диаграммы. Новые методы, такие как объектно-
190 ориентированные методы моделирования, расширяют концепцию моде- лирования, однако большинство используемых в них подходов, тем не менее, базируются на известных и проверенных временем принципах.
Хорошая модель – это модель, помогающая общению. Модели нуж- ны, для того чтобы было удобно обсуждать идеи и внутри команды раз- работчиков, и во всей организации в целом, подключая к этому процес- су и все заинтересованные стороны. Модели могут применяться для различных целей и покрывать самые разнообразные аспекты разработки системы. Так, например, одна модель может описывать общую структу- ру взаимодействия внутри всей организации, а другая – отображать все- го лишь одно конкретное функциональное требование к этой системе.
Моделирование дает следующие преимущества: поощряет использование точно определенной терминологии, одно- значность которой поддерживается в рамках разработки всей систе- мы; позволяет с помощью диаграмм получить наглядное представление системных спецификаций и архитектуры системы; позволяет рассматривать различные аспекты взаимодействия систе- мы с различных точек зрения; поддерживает системный анализ; обеспечивает возможность подтверждения достоверности некоторых аспектов поведения системы с помощью динамических моделей; позволяет постоянно совершенствовать систему посредством уточ- нения архитектуры, поддерживая генерацию тестов и исходного ко- да; дает возможность свободного общения различным организациям между собой, используя стандартные нотации.
Фиксация требований с помощью инструментов IBM Rational
RequisitePro и IBM Rational Software Modeler [1] помогает найти ответы на вопросы «кто?», «что?», «почему?» и «как?» применительно к биз- нес-требованиям [4]. Своевременное создание эффективных бизнес- решений начинается с понимания требований. Хороший анализ требо- ваний способен существенно повысить шансы на разработку решений, успешно преодолевающих имеющуюся проблему. Управление требова- ниями требует наличия адекватных связей со средствами, которые осу- ществляют их выполнение.
Инструмент Rational RequisitePro предоставляет возможности для фиксации требований, определения требований и управления требова- ниями. Инструмент IBM® Rational® Software Architect поддерживает моделирование на языке UML, что позволяет показать возможности для реализации этих требований. Инструмент RequisitePro интегрирован с инструментом Rational Software Modeler, что позволяет визуализировать требования и соединять элементы модели с требованиями, реализуемы- ми посредством этих элементов.
Продукт RequisitePro предоставляет несколько шаблонов требова- ний, которые вы сможете использовать для конфигурирования баз дан-
191 ных требований с необходимыми типами требований в соответствии с потребностями конкретного проекта.
Хотя эти шаблоны весьма полезны, для некоторых пользователей они могут оказаться недостаточно ориентированными на бизнес или недостаточно общими, чтобы быть применимыми на протяжении всего жизненного цикла разработки программных систем. В результате тре- бования могут оказаться сложны для их применения бизнес- аналитиками вследствие неподходящих типов требований и отношений между ними. Кроме того, это может привести к усложнению связей ме- жду базами данных RequisitePro, которые содержат разные типы требо- ваний для поддержки приложений на протяжении всего жизненного цикла.
Инструмент Rational Software Modeler способен создавать модели на основе применяемых профилей. Эти профили можно использовать в качестве UML-расширений для поддержки визуального моделирования требований. Этот инструмент также интегрирован с RequisitePro, что позволяет создавать и связывать требования с помощью различных ин- струментов. В состав Rational Software Modeler включены следующие профили [4]: профиль Analysis (анализ); профиль Business Modeling (бизнес-моделирование); профиль Software Services (бизнес-сервис).
Профиль Business Modeling имеет стереотипы Business Goal (бизнес- цель) и Business Service (бизнес-сервис), которые соответствуют типам требований в RUP-шаблонах RequisitePro. Кроме того, существуют ти- пы требований для моделирования разных стилей сценариев примене- ния (use case), в том числе бизнес-сценариев и системных сценариев.
Однако эти профили поддерживают моделирование ограниченного чис- ла требований, особенно применительно к бизнес-требованиям.
Многие клиенты IBM для моделирования требований создают свои собственные шаблоны RequisitePro и профили UML. Однако это может привести к появлению нестандартных требований и несогласованных отношений между требованиями и средствами их реализации. Более стандартизованный подход к управлению требованиями упрощает инте- грацию бизнес-сервисов. Таким образом, можно ограничиться стан- дартным шаблоном RequisitePro и соответствующим профилем UML, который поддерживает возможности управления требованиями. Нали- чие такого стандарта не только расширяет возможности моделирования требований, но и позволяет разрабатывать инструменты, способные управлять требованиями более эффективно за счет способности интер- претировать смысл требований и их отношения с другими артефактами в процессе проектирования и создания решения.
5.1.3. Разработка программных систем, управляемая моделями
Развитие идеи моделирования для решения отдельных задач привело к новому подходу разработки программного обеспечения – разработке,
1.
IBM
Rational
RequisitePro, http://www.interface.ru/home.asp?artId=311 2.
IEEE Standard Glossary of Software Engineering Terminology, http://www.andaim.ru/computer_engineering/10363-1132.html
3.
RuGost
-
Разработка документации по
ГОСТ, http://www.rugost.com/
4.
Байкин А., Новичков А. Пять уровней зрелости требований http://www.ibm.com/developerworks/ru/library/r- requirements/index.html#autor1 5.
Боэм Б.У. Инженерное проектирование программного обеспе- чения: Пер. с англ. – М.: Радио и связь. 1985. – 512 с.
6.
Брукс Ф.П. Как проектируются и создаются программные ком- плексы. (Мифический человекомесяц). Пер. с англ. – М.: Наука 1970 7.
Буч Г., Рамбо Д., Якобсон И. Язык UML, Руководство пользова- теля. 2-е изд.: Пер. с англ. мухин Н. – М.: ДМК Пресс, 2007. – 496 с.
8.
Вали У., Лейбович Л., Превост Э. и др. Управление бизнес- процессами: от моделирования до мониторинга с использованием про- дуктов WebSphere V6.: Пер. с англ. ibm.com/redbooks 2007. – 423 c.
186 9.
ГОСТ
Р
ИСО
9000
ГОСТ
Р
ИСО
9000http://urvista.ru/certification/sert-info/sert-stand/iso-9000-standard- series/iso-9000-standard/?_openstat=ZGlyZWN0LnlhbmRle-
C5ydTs0MzAwODg2OzUwNjAzNTU2O3lhbmRleC5ydTpwcmVtaXVt
10. Кватрани Т., Палистрает Д. Визуальное моделирование с помо- щью IBM Rational Software Architect и UML. Пер. с англ. – М.: КУДИЦ-
ПРЕСС. – 2007. – 192 с.
11. Майерс Г. Надежность программного обеспечения: Пер. с англ.
– М .: Мир, 1980. – 360 с.
12. Назаров С.В. Операционные системы специализированных вы- числительных комплексов: теория построения и системного проектиро- вания. – М.: Машиностроение, 1989. – 400 с.
13. Назаров С.В. Проектирование архитектуры программных сис- тем. Разработка, анализ и управление требованиями. Сборник научных трудов по материалам международной научно-практической конферен- ции «Перспективные инновации в науке. Образовании, производстве и транспорте ’2010», том 3 Технические науки. – Одесса: Черноморье,
2010. с. 27 – 42 14. Назаров С.В. Сложность программной системы. Сборник науч- ных трудов по материалам международной научно-практической кон- ференции «Современные направления теоретических и прикладных ис- следований ‘2011», том 2 Технические науки. – Одесса: Черноморье,
2011. с. 58 – 65 15. Новичков А. Роль процесса Управления Требованиями при раз- работке сложных программных систем. Практика применения методо- логии IBM RUP и инструмента IBM Rational RequisitePro, http://www.cmcons.com/articles/upravlenie_trebovanijami-
_instrument_ibm_rational_r/
16. Новичков А., Карабанова Б. Моделирование бизнес-процессов автоматизируемой предметной области при помощи диаграмм деятель- ности
(Activity diagram) с использованием
RSA, http://www.ibm.com/developerworks/ru/library/r-rsa/index.html
17. Полис Г., Огастин Л., Лоу К., Мадхар Д. Разработка программ- ных проектов на основе Rational Unnified Process (RUP). – М.: ООО
«Бином-Пресс», 2009. – 256 с.
18. Тавассоли Д. Управление требованиями. Десять шагов на пути к совершенству, http://www.swd.ru/files/pdf/IBM_uspeh_edit1.pdf
19. Терехов А.Н. Технология программирования: Учебное пособие/
А.Н. Терехов. – М.: Университет информационных технологий; БИ-
НОМ. Лаборатория знаний. 2006. – 148 с.
20. Уровни требований к программному обеспечению http://www.atis.ru/DocItem.aspx?groupId_10=8&itemId_10=15 21. Фасбиндер М. Новые возможности версии WebSphere Business
Modeler
V6.2. http://www.ibm.com/developerworks/ru/library/wes-
0812_fasbinder4/#author1 22. Шураков В.В. Надежность программного обеспечения систем обработки данных: Учебник для вузов. – М.: Статистика, 1981. – 216 с
187
Глава 5
РАЗРАБОТКА ПРЕДВАРИТЕЛЬНОГО ВНЕШНЕГО
ПРОЕКТА
5.1. Представление и анализ требований
5.1.1. Требования в V-модели Халла
Жизненно важная часть проектирования любых систем – это разра- ботка требований, которая, в первую очередь, определяет саму про- блемную область, а затем последовательно соотносит все последующие технические решения с конкретными проблемами из этой предметной области [29]. Требования являются основой для любого проекта. Они определяют те потребности заинтересованных сторон – пользователей, потребителей, поставщиков, разработчиков и самого бизнеса – которые являются для них необходимыми, а также тот функционал, которым система должна впоследствии обладать, чтобы удовлетворить эти по- требности.
Как отмечалось выше, чтобы стать всем понятными, требования в большинстве случаев пишутся на обычном языке, что привносит про- блемы другого рода: необходимость полностью и однозначно обозна- чить проблемы и зафиксировать потребности без использования про- фессионального жаргона или предварительных договоренностей. Это весьма сложная задача. Только согласованные требования могут быть основой для проекта, однако с течением времени у заинтересованных сторон может становиться все больше и больше требований, причем интересы сторон могут вступать в конфликт между собой. Кроме того, потребности могут быть нечетко выражены в начале проекта, их удов- летворение может быть ограничено факторами, лежащими в неконтро- лируемой области, на удовлетворение потребностей могут влиять дру- гие цели проекта, которые, в свою очередь, тоже могут меняться с тече- нием времени. Согласованные требования обеспечивают базу для пла- нирования разработки системы и ее приемки по завершении работ.
Можно ли дать оценку влияния предполагаемого изменения без де- тальной проработки модели системы? С другой стороны, что будет, ес- ли отменить ранее внесенные изменения? Даже если проблема и ее ре- шение определены, необходимо оценить риски, которые могут привести к провалу проекта. Организация работы с требованиями позволяет управлять рисками на самых ранних стадиях разработки. Например, если риск, вытекающий из определенного требования, может быть от- слежен, может быть проведена оценка его влияния, вероятность появле- ния, и, как следствие, может быть разработан предварительный план по предотвращению и устранению последствий этого риска.
Таким образом, требования являются базой для планирования проек- та, управления рисками, приемочного тестирования, установления ком- промиссов (согласований) и управления изменениями.
188
Анализ требований включает [2]: обнаружение и разрешение конфликтов между требованиями; определение границ задачи, решаемой создаваемым программным обеспечением; в общем случае - определение границ и содержания программного проекта; детализацию системных требований для установления программных требований.
В SWEBOK [2] отмечается, что традиционный взгляд на анализ тре- бований часто сфокусирован или уменьшен до вопросов концептуаль- ного моделирования с использованием соответствующих аналитических методов, одним из которых является SADT – Structured Analysis and
Design Technique (методология структурного анализа и техники проек- тирования), известный по нотациям IDEF0 (функциональное моделиро- вание – стандарт IEEE 1320.1), IDEF1X (информационное моделирова- ние – стандарт IEEE 1320.2, известный также как IDEFObject), часто применяемым как для моделирования бизнес-процессов, так и структур данных, в частности – реляционных баз данных.
Не следует считать, что разработка требований – это единичная фаза, которая выполняется в начале разработки продукта. Очевидно, что тре- бования, разработанные в начале проекта, так или иначе, используются на его самом последнем этапе (рис. 5.1). Классическая V-модель [29], описывающая различные стадии проекта, в основном базируется на свя- зи между требованиями и их тестированием.
Рис. 5.1. Классическая V-модель Халла
V-модель отображает также системную разработку в терминах уров- ней, где каждый уровень соотносится с определенным этапом разработ- ки. Несмотря на то, что на каждом уровне могут использоваться не- сколько различных процессов, основной принцип работы с требования- ми не меняется. Требования могут выступать также в роли связи между
189 проектами. Это хорошая идея, по мнению Халла [29], потому что орга- низации-разработчики желают: максимально увеличить использование наработок в разных проек- тах; управлять семействами сходных продуктов; использовать программное управление для согласования действий; оптимизировать разработку, используя опыт предыдущих проектов.
Хороший набор пользовательских требований может обеспечить краткое и не техническое описание того, что будет разработано, на уровне, который доступен для понимания руководством. Аналогичным образом, системные требования могут представлять собой прекрасное техническое описание проекта. Эти два шага служат основой для всех последующих действий в рамках проекта.
Поскольку требования играют такую важную роль в разработке сис- тем, с ними нужно постоянно работать. При внесении изменения необ- ходимо в основном выполнить следующие действия: принять или отклонить изменение; согласовать стоимость изменения с заказчиками (поставщиками); организовать работы по переделке.
Основной концепцией, позволяющей проводить анализ влияний та- кого рода, является возможность установления и последующего контро- ля связей между требованиями. Можно утверждать, что управление из- менениями является важной частью работы с требованиями. Способ- ность руководителя управлять проектом в значительной степени зави- сит от качества поставленного процесса работы с требованиями.
5.1.2. Моделирование в определении требований и спецификаций
Важно понимать взаимосвязь между разработкой требований и сис- темным моделированием. Употребление термина моделирование требо- ваний неверно по сути [5]. Моделируется реализация системы, а не тре- бования к ней. Моделирование поддерживает наиболее творческий про- цесс – разработку реализации системы, выработку конкретных систем- ных решений.
Системное моделирование вносит дополнительную формальность в процессы анализа и проектирования. При разработке любой системы часто используются схемы и рисунки, которые помогают наглядно ото- бразить некоторые аспекты разработки. Системное моделирование формализует это наглядное представление не только с помощью диа- грамм, выполненных с использованием стандартных нотаций (синтак- сиса), но и обеспечивает среду (средства) для понимания и обсуждения идей, связанных с процессом разработки [29].
Искусство моделирования, по мнению многих известных ученых и инженеров, является самой творческой частью работы системного раз- работчика. В большинстве случаев модели представляют собой некий визуальный ряд, в котором для отображения информации используются взаимосвязанные диаграммы. Новые методы, такие как объектно-
190 ориентированные методы моделирования, расширяют концепцию моде- лирования, однако большинство используемых в них подходов, тем не менее, базируются на известных и проверенных временем принципах.
Хорошая модель – это модель, помогающая общению. Модели нуж- ны, для того чтобы было удобно обсуждать идеи и внутри команды раз- работчиков, и во всей организации в целом, подключая к этому процес- су и все заинтересованные стороны. Модели могут применяться для различных целей и покрывать самые разнообразные аспекты разработки системы. Так, например, одна модель может описывать общую структу- ру взаимодействия внутри всей организации, а другая – отображать все- го лишь одно конкретное функциональное требование к этой системе.
Моделирование дает следующие преимущества: поощряет использование точно определенной терминологии, одно- значность которой поддерживается в рамках разработки всей систе- мы; позволяет с помощью диаграмм получить наглядное представление системных спецификаций и архитектуры системы; позволяет рассматривать различные аспекты взаимодействия систе- мы с различных точек зрения; поддерживает системный анализ; обеспечивает возможность подтверждения достоверности некоторых аспектов поведения системы с помощью динамических моделей; позволяет постоянно совершенствовать систему посредством уточ- нения архитектуры, поддерживая генерацию тестов и исходного ко- да; дает возможность свободного общения различным организациям между собой, используя стандартные нотации.
Фиксация требований с помощью инструментов IBM Rational
RequisitePro и IBM Rational Software Modeler [1] помогает найти ответы на вопросы «кто?», «что?», «почему?» и «как?» применительно к биз- нес-требованиям [4]. Своевременное создание эффективных бизнес- решений начинается с понимания требований. Хороший анализ требо- ваний способен существенно повысить шансы на разработку решений, успешно преодолевающих имеющуюся проблему. Управление требова- ниями требует наличия адекватных связей со средствами, которые осу- ществляют их выполнение.
Инструмент Rational RequisitePro предоставляет возможности для фиксации требований, определения требований и управления требова- ниями. Инструмент IBM® Rational® Software Architect поддерживает моделирование на языке UML, что позволяет показать возможности для реализации этих требований. Инструмент RequisitePro интегрирован с инструментом Rational Software Modeler, что позволяет визуализировать требования и соединять элементы модели с требованиями, реализуемы- ми посредством этих элементов.
Продукт RequisitePro предоставляет несколько шаблонов требова- ний, которые вы сможете использовать для конфигурирования баз дан-
191 ных требований с необходимыми типами требований в соответствии с потребностями конкретного проекта.
Хотя эти шаблоны весьма полезны, для некоторых пользователей они могут оказаться недостаточно ориентированными на бизнес или недостаточно общими, чтобы быть применимыми на протяжении всего жизненного цикла разработки программных систем. В результате тре- бования могут оказаться сложны для их применения бизнес- аналитиками вследствие неподходящих типов требований и отношений между ними. Кроме того, это может привести к усложнению связей ме- жду базами данных RequisitePro, которые содержат разные типы требо- ваний для поддержки приложений на протяжении всего жизненного цикла.
Инструмент Rational Software Modeler способен создавать модели на основе применяемых профилей. Эти профили можно использовать в качестве UML-расширений для поддержки визуального моделирования требований. Этот инструмент также интегрирован с RequisitePro, что позволяет создавать и связывать требования с помощью различных ин- струментов. В состав Rational Software Modeler включены следующие профили [4]: профиль Analysis (анализ); профиль Business Modeling (бизнес-моделирование); профиль Software Services (бизнес-сервис).
Профиль Business Modeling имеет стереотипы Business Goal (бизнес- цель) и Business Service (бизнес-сервис), которые соответствуют типам требований в RUP-шаблонах RequisitePro. Кроме того, существуют ти- пы требований для моделирования разных стилей сценариев примене- ния (use case), в том числе бизнес-сценариев и системных сценариев.
Однако эти профили поддерживают моделирование ограниченного чис- ла требований, особенно применительно к бизнес-требованиям.
Многие клиенты IBM для моделирования требований создают свои собственные шаблоны RequisitePro и профили UML. Однако это может привести к появлению нестандартных требований и несогласованных отношений между требованиями и средствами их реализации. Более стандартизованный подход к управлению требованиями упрощает инте- грацию бизнес-сервисов. Таким образом, можно ограничиться стан- дартным шаблоном RequisitePro и соответствующим профилем UML, который поддерживает возможности управления требованиями. Нали- чие такого стандарта не только расширяет возможности моделирования требований, но и позволяет разрабатывать инструменты, способные управлять требованиями более эффективно за счет способности интер- претировать смысл требований и их отношения с другими артефактами в процессе проектирования и создания решения.
5.1.3. Разработка программных систем, управляемая моделями
Развитие идеи моделирования для решения отдельных задач привело к новому подходу разработки программного обеспечения – разработке,