АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем

• Название: Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
• Дата: 03.06.2022
• Размер: 4.65 Mb.
• Имя файла: АРИС Текст 2.docx
• Тип: Документы; #568218
• страница: 11 из 30

Контрольные вопросы

1. Что такое РС?

2. Каким образом можно классифицировать РС?

3. Перечислите и охарактеризуйте основные сетевые архитектурные стили.

4. Что такое сокет?

5. Каким образом процессы взаимодействуют через сокеты?

6. Что такое вызов удаленных процедур?

7. Каково назначение заглушек?

8. Что такое маршаллинг?

9. Перечислите основные достоинства и недостатки RPC.

10. Каким образом взаимодействуют удаленные объекты?

11.Как работает RMI?

12. Зачем нужно промежуточное ПО?

13. Что такое распределенная файловая система?

14. Что такое «Архитектура "клиент-сервер»?

15. В чем различие между архитектурой с тонким и толстым клиентом?

16. Что такое «Многозвенное приложение»?

17. В чем состоит идея микроядернй архитектуры?

18. Перечислите и охарактеризуйте альтернативные подходы к удаленному выполнению заданий.

19. Что такое кластер?

20. Что такое грид?

21. Охарактеризуйте стек протоколов Грид.

22. Для чего нужен Globus Toolkit?

23. Перечислите и охарактеризуйте основные механизмы работы с сообщениями.

24. Для решения каких задач используют MPI?

25. Что такое очереди сообщений?

26. Как работает электронная почта?

27. Что такое распределенные системы документов?

28. Как работает Веб-сервер?

29. Что такое CGI?

30. Что такое URL?

31. Что такое Lotus Notes?

32. Определите понятие виртуализации.

33. Что такое виртуальная машина?

34. Что такое паравиртуализация виртуализация?

35. Что такое полная виртуализация?

36. Что такое виртуализация на уровне ОС?

37. Что такое виртуализация серверов?

38. Зачем нужен гипервизор?

39. Что такое облачные вычисления?

40. Перечислите и охарактеризуйте основные типы облачных сервисов.

41. Что такое частные облака?

42. Какие элементы включает в себя агентная платформа FIPA?

ГЛАВА 4. ТРЕБОВАНИЯ К ИНФОРМАЦИОННЫМ СИСТЕМАМ. УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ

4.1. Типы требований

Работа с требованиями является важнейшей составной частью процесса создания ИС. Это очень непростой этап, и ошибки, допущенные при определении требований к ИС, очень дорого обходятся разработчикам, поскольку весь процесс проектирования или его существенную часть приходится проводить заново. Следует отметить, что выбор основных архитектурных решений осуществляется на этапе формирования требований. Правильное определения требований и эффективное управление требованиями — это краеугольные камни успеха любого IT-проекта. До настоящего времени сохраняется ситуация, при которой около 10 % проектов оканчиваются крахом и не менее 20 % существенно превышают смету расходов по причине неправильного определения требований к системе [58]. В последние годы практически все разработчики уделяют самое пристальное внимание работе с требованиями, но ситуацию это не спасает, поскольку дело не в том, что аналитики не учли требования тех или иных заинтересованных сторон, а в том, что требования постоянно изменяются. Прежде всего, изменяется окружение, в котором работает или должна работать система: на рынке появляются конкурирующие продукты, появляются новые ИТ-технологии и т.д. Таким образом, аналитик, вырабатывающий требования к системе, должен прогнозировать развитие ситуации и учитывать возможность появление новых требований. Основным документом, регулирующим работу с требованиями, на момент написания книги является стандарт [59]. Подробное описание возможных подходов к работе с требованиями можно найти в [60, 61, 62].

В соответствии со стандартом[59], требование — это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо, измеримо и необходимо для приемки продукта или процесса заказчиком.

Требование должно обладать следующими свойствами:

1. Единичность — требование описывает одну и только одну сущность.

2. Завершенность — требование полностью определено в одном месте.

3. Реализуемость — требование может быть исполнимо с учетом возможностей доступных технологий и ресурсов.

4. Непротиворечивость — требование не противоречит другим требованиям и соответствует документации.

5. Атомарность — требование нельзя разделить на более мелкие требования.

6. Отслеживаемость — требование полностью или частично соответствует бизнес-потребностям заинтересованных лиц.

7. Актуальность — требование не стало устаревшим с течением времени.

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

9. Проверяемость — возможность составление теста, с помощью которого можно проверить выполнено ли требование.

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

Основные типы требований. На рис. 4.1 приведена укрупненная схема классификации требований.



Рис. 4.1. Классификация требований

Требования могут быть сформулированы на 3 разных уровнях: бизнес-уровне, пользовательском уровне и системном уровне.

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. Бизнес-требование – это описание целей, которые должны быть достигнуты за счет создания системы.

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии, т.е. требования пользователей описывают то, что они могут делать с помощью системы.

Термином системные требования (system requirements) обозначают высокоуровневые требования, как ко всей ИС, так и к отдельным подсистемам. Системные требования к подсистемам формируются на основе требований ко всей системе. Системные требования формулируются в терминах, которыми пользуются разработчики системы.

Можно выделить 4 основные группы источников требований (заинтересованных сторон): потенциальные пользователи ИС, внутренние требования к продукту, внешние требования к продукту. Потенциальные пользователи, это те, кто непосредственно работает или будет работать с системой. Внутренние требования – это требования организации, например, ИС должна позволить организации выйти на новый для нее рынок. Это, как правило, бизнес требования. Доменные требования отражают требования окружения, в котором работает создаваемая ИС. Доменные требования формулируются в терминах предметной области и могут использовать профессиональную терминологию. Например, это могут быть специфические требования ко всем системам военного назначения, или всем медицинским системам. Внешние требования – это требования со стороны государственных и негосударственных организаций. Чаще всего они выражаются в форме стандартов.

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

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

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

Нефункциональные требования. Это требования, которые напрямую не связаны с конкретными сервисами, которые проектируемая ИС предоставляет конечному пользователю. Нефункциональные требования можно рассматривать как ограничения, накладываемые на конкретные свойства ИС, например требования, связанные с поддержанием интерфейсов с определенными внешними системами, такими как, например, MS Office. К нефункциональным требованиям относят такие требования как время реакции, надежность, удобство обслуживания и т.п. Такие нефункциональные характеристики как производительность, безопасность, доступность относятся ко всей ИС. В определенных ситуациях нефункциональные характеристики могут оказаться даже более важными, чем функциональные. Например, если графический редактор не удобен в работе, то наличие некоторой дополнительной функциональности не сможет обеспечить его успех на рынке. Иногда бывает трудно определить, какой именно компонент реализует ту или иную функцию, но еще труднее это сделать применительно к нефункциональным требованиям. Достаточно часто одно функциональное требование может определить архитектуру всей системы. Типовая проблема, которая появляется при работе с нефункциональными требованиями, состоит в том, что очень часто потенциальные пользователи формируют их в форме целей. Например, пользователь считает, что проектируемая система должна быть проста в использовании, или система должна быть спроектирована таким образом, чтобы минимизировать ошибки оператора. Очевидно, что проверить удовлетворяет ли система таким требованиям невозможно. Поэтому при формулировании нефункциональных требований насколько это возможно надо использовать метрики, которые можно проверить. Например, указанные выше требования можно сформулировать следующим образом. Для подготовки оператора достаточно 16 часового курса, после прохождения которого оператор допускает в течение смены не более 3 ошибок.

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

При составлении документации по требованиям к системе не рекомендуется очень жестко разделять функциональные и нефункциональные требования, поскольку в этом случае оказывается сложно проследить взаимосвязи между ними.

4.2. Процесс разработки требований

Процесс выработки требований является частью процесса разработки ИС, который реализуется в рамках 4 основных подпроцессов [59].

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

2. Выделениеианализтребований (Requirements elicitation and analysis). Это процесс формирования списка требований посредством анализа существующих систем, общения с потенциальными пользователями. Для формирования списка требований может потребоваться разработка ряда моделей и прототипов.

3. Спецификация требований (Requirements specification). Эту активность можно определить как процесс упорядочения собранной информации о требованиях.

4. Валидация требований (Requirements Validation) . Это активность, связанная с проверкой требований на полноту, непротиворечивость и реалистичность, т.е. на наличие реальной потребности. На этом этапе обнаруживаются разного рода неточности и ошибке в спецификации требований. Обычно этот процесс носит циклический характер, при этом могут появляться новые требования. Результатом данного этапа является окончательная спецификация требований.

Обобщенная структура процесса формирования требований приведена на рис. 4.2.



Рис. 4.2. Обобщенная структура процесса формирования требований

4.3. Оценка реализуемости

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

Сам процесс оценки реализуемости обычно предполагает сбор информации, ее оценка и написание отчета. В качестве источников информации могут выступать менеджеры организации заказчика, потенциальные пользователи, ИТ специалисты, разного рода эксперты по конкретным вопросам. Ниже приведен далеко не полный список вопросов, ответы на которые должны содержаться в отчете.

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

2. Какова стоимость перехода на новую систему.

3. Используются ли в системе технологии, ранее не применяемые в организации.

4. Какими будут последствия для организации, если система не будет создана.

В отчете могут содержаться предложения по изменению состава требований. Обычно процесс оценки реализуемости занимает не более 2-3 недель.

4.4. Выделение и анализ требований

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

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

1. Выявление требований (Discovery). Процесс взаимодействия с заинтересованными сторонами с целью выявление их требований, а также формулирование доменных требований.

2. Классификация и организация требований (Сlassification and organization). Процесс упорядочения списка выявленных требований. Для упорядочения требований обычно используется архитектурная модель, применительно к которой формируются требования к отдельным подсистемам. На этом этапе разрабатывается архитектурная модель. Таким образом, можно утверждать, что процесс архитектурного проектирования и процесс разработки требований – это, по существу один и тот же процесс.

3. Согласование требований. Требования отдельных заинтересованных сторон могут противоречить друг другу. В этом случае необходимо, чтобы эти заинтересованные стороны согласовали свои требования.

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

1. Заинтересованные стороны часто не могут четко сформулировать свои требования и начинают выставлять нереалистичные требования.

2. Потенциальные пользователи формулируют свои требования в терминах предметного домена и аналитикам трудно их понять.

3. Разные заинтересованные лица формулируют свои термины в разной форме, от аналитика требуется определить все заинтересованные стороны и обнаружить конфликты в требованиях.

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

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

Основными приемами, используемыми на данном этапе являются: интервьюирование, сценарии варианты использования.

Интервьюирование. Обычно используется 2 типа интервью: в первом случае (закрытое интервью) заинтересованное лицо отвечает на заранее определенный набор вопросов, а во втором случае (открытое интервью) – список вопросов заранее не определяется. На практике чаще всего используется некоторая смесь интервью этих двух типов. Механизм интервью хорошо работает при выявлении требований конечных пользователей, однако не всегда работает на уровне выявления доменных требований, поэтому для выявления доменных требований аналитикам приходится работать с документацией.

Сценарии. Конечному пользователю часто бывает проще объяснить свои требования на конкретных примерах. Сценарии обычно используются для уточнения деталей того, как пользователь хотел бы общаться с системой. В качестве языка описания сценариев обычно используется диаграммы вариантов использования (use case), входящих с состав UML [63] который будет описан ниже.

4.5. Валидация требований

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

1. Рецензирование списка требований несколькими экспертами.

2. Разработка прототипа система. (Это может быть, например, модель экранных форм приложения).

3. Оценка возможности создания теста. Каждое требование должно быть тестируемым. Если не удается составить тест, который может проверить выполнение некоторого требования, то это может означать, что реализация этого требования может оказаться очень сложным, поэтому на это требование следует обратить особое внимание и, по возможности, реструктуризировать данное требование.

4.6. Документирование требований

Документирование или спецификация это процесс, в результате которого в качестве артефакта появляется документ, в котором описывается то, что должны сделать разработчики ИС. В нем детально описываются как пользовательские, так и системные требования. Иногда они интегрируются в единое описание, иногда сначала излагаются пользовательские требования, а затем подробно описываются системные требования.

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

Спецификация требований выполняется в интересах нескольких категорий заинтересованных сторон (stakeholders). В табл. 4.1 приведен список основных заинтересованных лиц и их интересы применительно к списку требований.

Таблица 4.1.

Основные заинтересованные лица и их интересы

	Заинтересованное лицо	Интерес
1	Покупатель, пользователь	Проверка степени соответствия потребностям
2	Менеджер проекта	Планирование процесса разработки
3	Программист	Понимание того, какую систему требуется разработать
4	Специалист по тестированию	Разработка тестов
5	Системный администратор	Понимание структуры системы и того как она должна функционировать

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

В соответствии со стандартом [59] спецификация требований включает в себя следующие разделы.

1. 
   Преамбула, в которой приводится самая общая информация о системе, описывается история версий документа и указываются основные отличия текущей версии от предыдущих версий.
   
2. 
   Введение, в котором описывается назначение системы, ее основная функциональность, возможные варианты взаимодействия с другими системами и возможные варианты использования.
   
3. 
   Глоссарий, в котором приводятся определения основных терминов.
   
4. 
   Пользовательские требования, описывающие сервисы, предоставляемые пользователю системой, здесь также описываются нефункциональные требования. Описание пользовательских требований обычно выполняется на естественном языке, понятном конечному пользователю. Здесь же перечисляются стандарты, которым должна соответствовать разрабатываемая система.
   
5. 
   Описание системной архитектуры, содержащее высокоуровневое описание системы в терминах основных подсистем и способов их взаимодействия.
   
6. 
   Системные требования – подробно описываются функциональные и нефункциональные требования, определяются интерфейсы с внешними системами.
   
7. 
   Системные модели, описывающие функционирование системы и ее взаимодействие с внешним миром. Эти описания ориентированы на тех, кто должен разрабатывать систему. Они должны быть максимально точны и подробны. Для описания системных моделей могут использоваться объектные модели, модели потоков данных, семантические модели.
   
8. 
   Возможные направления эволюции системы – рассматриваются возможны варианты развития системы, обусловленные развитием элементной базы, изменениями потребностей пользователей и т. п. Фактически речь идет о формировании требований к следующим поколения систем данного класса. Основная цель данного раздела – помочь разработчикам избежать решений, которые будут ограничивать возможности системы в плане модернизации.
   
9. 
   Приложения – в частности, при проектировании крупных систем могут содержать описания требований к подсистемам второго уровня.
   
10. 
    Индексы – чаще всего это алфавитный указатель используемых в описании терминов.
    

4.7. Управление требованиями

Требования к крупномасштабным системам постоянно меняются. Для этого есть много причин. Во-первых, когда система знаний о внешнем мире практически никогда не бывают исчерпывающей, во-вторых, со временем меняется сама окружающая среда, в третьих, заказчики (покупатели) системы – это не одни и те же люди. Как правила закупками занимаются менеджеры, конечные пользователи – это специалисты в предметной области, и их понимание требований могу отличаться.

Процесс управления требованиями можно определить как процесс отслеживания изменений требований к системе. Организация этого процесса состоит в том, чтобы организовать поток запросов на изменения требования от всех заинтересованных сторон. Этот процесс может стартовать после появления первого варианта списка требований. Процесс управления требованиями включает 3 фазы: анализ проблемы и изменение спецификации, анализ предлагаемых изменений, включая оценку стоимости изменений, реализация изменений. При этом в обсуждении должны принимать участие заинтересованные стороны, которые являлись инциаторами процесса изменений требований. Фаза анализ предлагаемых изменений – это, прежде всего, оценка стоимости изменений в денежном и временном исчислении. Содержание фазы реализация изменений зависит от того, на какой стадии жизненного цикла находится система. В простейшем случае, если команда не приступила к проектированию – это может быть переделка спецификации требований. Если система уже спроектирована и находится в эксплуатации, то может потребоваться модификации системы. В этом случае разрабатывается план перехода на новую версию системы.

4.8. Инструментальные средства поддержки процесса разработки требований

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

Структурирование требований является наилучшим способом их организации, позволяя более эффективно управлять ими во избежание дублирований или пропусков. При работе с требованиями следует иметь в виду, что процесс управление требованиями, с одной стороны, - это процесс обмена информацией между заинтересованными сторонами, а, с другой стороны, требования – это язык общения между заинтересованными сторонами. Поэтому важно, чтобы требования корректно передавали смысл и правильно связывались между собой. Процесс работы с требованиями – крайне ответственный и слабо формализуемый процесс. Над формированием требований должна работать команда, которая включает все категории заинтересованных лиц, в состав которых входят аналитики, архитекторы, конечные пользователи, менеджеры разного уровня, эксперты и т.д. Для поддержки процесса работы с требованиями уже создано и продолжают создаваться инструментальные средства. В разные годы были популярны такие пакеты коммерческие пакеты как: IBM Rational RequisitePro, Borland CaliberRM, Sybase PowerDesigner, имелись также и бесплатные системы, такие как OSRMT — Open Source Requirements Management Tool. Эти инструменты имели разные функциональные возможности и, соответственно, существенно разную стоимость.

В основу функционирования инструментальных средств, поддерживающих работу с требованиями, положена объектная модель представления требований. Требования представляются в виде совокупности объектов, имеющих атрибуты.

В качестве атрибутов требований могут выступать такие параметры как: приоритет (priority), состояние (status), стоимость (cost), трудность при реализации (difficulty), стабильность (stability), назначенный (assigned to), источник (origin). Могут существовать иерархии требований. Можно описать взаимозависимости между требованиями. Между требованиями могут существовать связи типа связи родитель-потомок, может быть реализован механизм наследования. Иерархические связи позволяют представить общие требования как совокупность частных требований. Общепринятой объектно-ориентированной модели работы с требованиями нет. Объектные модели, реализованные в разных системах работы с требованиями отличаться.

На момент написания данного учебника одной из наиболее мощных и популярных систем управления требования была система DOORS (Dynamic Object Oriented Requirements System) - динамическая объектно-ориентированная система для работы с требованиями. Первоначально продукт был разработан компанией QSS Ltd (Оксфорд), затем был приобретен, компанией Telelogic, затем был приобретен фирмой IBM и включен в состав группы продуктов IBM Rational под названием Rational DOORS. На момент написания учебника последней была версия версии 9.5.

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

Архитектура DOORS. В DOORS все требования и связанная с ними информация хранятся в центральном репозидарии (БД), который, в идеале, поддерживаться в актуальном состоянии на протяжении всего жизненного цикла приложения.

В DOORS репозитарий организован в виде дерева, для построения которого используются 3 типа элементов (рис. 4.3): папки (folder), проекты (project) и модули (module). Собственно информация хранится в модулях. Проекты и папки используются в качестве контейнеров. Проект – это папка, предназначенная для хранения информации, относящейся к данному проекту или подпроекту.



Рис. 4.3. Структура базы данных DOORS

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

• 
  формальные (formal), предназначенные для хранения структурированных наборов данных;
  
• 
  описательные (descriptive), предназначенные для хранения неструктурированной первичной информации, такой как заметки сделанные в ходе интервью, переписка и т. п.;
  
• 
  линки (link), предназначенные для хранения информации о связях между требованиями.
  

Пользовательский интерфейс DOORS очень похож на интерфейс Windows Explorer и позволяет легко и удобно просматривать содержимое модулей по схеме Папка  Проект  Модуль. В окне DOORS подобно тому, как это делается в Windows Explorer, пользователь может управлять структурой БД. Можно создавать, перемещать, переименовывать, удалять и просматривать содержимое папок, проектов, модулей. Пользователь может просматривать содержимое БД различным способов, для этого используется система видов (View): стандартный вид (Standard View), оглавление (Outline View) и иерархическое представление (Explorer View). В первом случае содержимое БД отображается как текстовый документ, во втором – отображаются только заголовки, а в третьем отображается в виде иерархической структуры. Кроме того, имеется возможность работы с графикой и таблицами.

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

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

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

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

DOORS позволяет создавать отчеты, отражающие связи между объектами с помощью анализатора связей (Traceability Explorer), который позволяет пользователю в одном окне видеть связи сразу между многими документами.

В DOORS имеется встроенный предназначенный для расширения функций и управления ими, который называется Rational DOORS eXtension Language (DXL). DXL - это простой язык сценариев, который предназначен для автоматизация рутинных и сложных задач, таких как вычисление значений атрибутов, обработки событий путем активации пользовательских программ и добавления в меню собственных пунктов. Синтаксис DXL близок к синтаксису таких языков как C и C++.

DOORS предоставляет широкие возможности импорта и экспорта информации из документов, таблиц и баз данных, включая RTF, Word, Excel, Access, Plain Text, HTML, PowerPoint, MS Project и многих других.

Для моделирования на UML с помощью можно использовать приложение DOORS/Analyst, которое является результатом интеграции DOORS с продуктом IBM Rational Tau, что позволяет создавать UML модели и диаграммы непосредственно в формальных модулях DOORS, размещая их внутри объектов.

В заключение следует заметить, что система DOORS является одной из мощных и дорогих систем работы с требованиями и ориентирована, прежде всего, на проектирование крупномасштабных систем [60, 61,62, 65].