В ЕА есть такая фишка как привязка Note(заметка) к внутренним элементам.
В частности в примере самого ЕА, есть заметки на многих диаграммах, в которых отображается текст — например, есть такой ВИ Закрыть аккаунт(счет), в нем есть сценарии — и описаны 4 потока событий... →
Есть Package1 содержащий Class1
Есть Package2 содержащий Instance :Class1
Теперь создадим копию Package1:
Экспортируем Package1 в файл XMI и обратно импортируем, установив флажок Strip GUID's.
Получаем Package3 содержащий самостоятельную копию Class1
Беда в том, что при этом меняется Instance :Class1
Если раньше это был Instance :Package1.Class1,.. →
Особенности проявились при переносе базы с MySQL наEAP
Рекомендуется драйвер MySQL ODBC driver version 3.51.12.00.
На закладках Advanced и Flags 1 драйвера нужно установить флаги "Don't Optimize Column Width" and "Return Matching Rows"... →
Разные справочники (Reference data) хранятся в репозитарии отдельно от диаграмм и элементов моделей и при импорте/экспорте пакетов модели не переносятся.
Для экспорта необходимо выбрать пункт меню Tools-Export Reference data-и из списка выбрать нужный справочник (например, для шаблонов встроенных документов — LinkedDocumentTemplate), ввести имя файла и т.д. .. →
Для группового доступа рецепт такой: корпоративная лицензия + сетевая база данных. Если с лицензией все гуд, то можно не заморачиваться, а выложить файлик eap на сеть в общедоступное место и всем его открывать — это получится групповой доступ к Access-файлу. Но если в районе 10 человек работает, лучше заморочиться на MS SQL или Oracle... →
В исследовательских целях пробовали скрестить еще EA 6.5 с SubVersion и со StarTeam (ST). Вроде работало, в StarTeam'е не понравилось то, что при check-out из EA устанавливался эксклюзивный лок на выгружаемый элемент. Но практически использовать не стали пока. Элементом конфигурации является 1 пакет, заметьте — пакет, а не диаграмма... →
Предположим у вас есть пакет Модель требований, в нем пакеты Функциональные требования и так дальше. Предположим, Вы хотите выделить все требования, которые были предложены к рассмотрению, но еще не рассматривались.
Выделяем этот пакет.
Идем Project/Documentation/RTF
В окне Generate RTF Documentation жмем кнопку Generate Options ... →
1 вариант (терапевтический) — открываем параметры RTF-отчета — окно Generate RTF Documentation. В нем ставим галочку Use Language Substitutions, после чего нажимаем кнопку Language… В открывшемся окне Customize RTF Language в списке Word Substitution List ищем слово на английском языке, которое мы хотим выводить по-русски, дважды щелкаем по нему мышкой и в появившемся маленьком окне вводим русский эквивалент слова... →
Такой элемент называется Composite Element. Чтоб элемент стал таким, выделяем его, открываем контекстное меню, выбираем пункт Advanced — Composite Element. После этого у нас на элементе в правом нижнем углу обычно появляется значок бесконечности, а при двойном клике мыши на элементе открывается свежесозданная диаграмма, которая находится под элементом (если смотреть в Project Browser)... →
Развернутый ответ на русском языке еще не готов, краткий ответ для знающих английский язык:
Возможность есть в версии Corporate, для настройки требует знания информации, изложенной на сайте производителя: Version Control http://sparxsystems.com/resources/version_control.html , Share http://sparxsystems.com/share.html , а также в хелпе к EA по ключевым словам User Security support... →
Антитребование — это некое утверждение, что не должна делать программа. Например: "Программа не должна иметь внешнего загрузчика файлов". Хорошая спецификация должна иметь антитребования, чтобы явно описать, что программа не должна делать.
.. →
— Перед началом проекта ознакомьте Клиента с его обязанностями:
1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса
2. Потратить столько времени, сколько необходимо, на объяснение требований
3. Точно и конкретно описать требования к системе
4. Принимать своевременные решения
5. Уважать определённую разработчиком оценку стоимости и возможность реализации ваших
требований
6... →
Наиболее известные — это Rational RequisitePro, Borland CaliberRM, Telelogic DOORS.
Все средства и их сравнительные характиристики указаны здесь:
http://www.uml2.ru/forum/index.php?topic=208.0
.. →
К действиям по управлению требованиями относятся:
— определение основной версии требований (моментальный срез требований для конкретной версии продукта);
— просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
— включение одобренных изменений требований в проект установленным способом;
— согласование плана проекта с требованиями;
— обсуждение новых обязательств, основанных на оценке влияния изменения требований;
— отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования;
— отслеживание статуса требований и действий по изменению на протяжении всего проекта... →
Набор требований, составляющий спецификацию, должен отвечать характеристикам:
— Полнота Никакие требования или необходимые данные не должны быть пропущены.
— Согласованность Согласованные требования не конфликтуют с другими требованиями такого же типа или с высокоуровневыми пользовательскими, системными или бизнес-требованиями. Несогласованность документов следует устранить до начала процесса разработки... →
Характеристики качества превосходных требований:
— Полнота Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
дартный флаг для выделения такого места... →
Спецификация требований не содержит деталей дизайна или реализации (кроме известных ограничений), данных о планировании проекта или сведений о тестировании. Для проекта, как правило, создаются требования других типов: документ, где описана среда разработки, ограничения бюджета, руководство
пользователя или требования для выпуска продукта и продвижения его в поддерживаемую среду... →
Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. ниже иллюстрирует способ представления этих типов требований.
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы... →
IEEE Standard Glossary of Software Engineering Terminology определяет требования как:
1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам
3... →
Выпущено множество книг как на английском языке, так и на русском:
