Лучший опыт: Управление требованиями
Управление требованиями включает:
- обнаружение, организацию и
документирование начальных требований
- установление и поддержание соглашений между заказчиком и исполнителем об
изменяющихся требованиях к системе
- отслеживание изменений и оценку их влияния на процесс и уже реализованные решения
© 2005, |
В.В.Хашковский, Д.П.Калачев. |
21 |
© 2004, |
Л.Б.Новиков |
|
Лучший опыт: Управление требованиями
Сбор требований – нетривиальная задача:
Требования не всегда очевидны
Требования не всегда удается ясно выразить словами
Есть много типов требований на разных уровнях абстракции
Число требований неуправляемо, если ими не управлять
Требования связаны друг с другом и с другими артефактами
Требования имеют уникальные свойства
Есть много заинтересованных лиц, имеющих разные интересы
Требования изменяются
© 2005, |
В.В.Хашковский, Д.П.Калачев. |
22 |
© 2004, |
Л.Б.Новиков |
|
Лучший опыт: Управление требованиями
Необходимые условия эффективного управления требованиями:
Поддержание ясных формулировок
Определение атрибутов для каждого типа требований
Указание трассируемости к другим требованиям и к другим проектным артефактам
© 2005, |
В.В.Хашковский, Д.П.Калачев. |
23 |
© 2004, |
Л.Б.Новиков |
|
Лучший опыт: Управление требованиями
Для представления функциональных требований используются прецеденты
Прецедент (Use Case) – это описание последовательности взаимодействий
пользователя с системой; она имеет
наблюдаемый результат, ценный для конкретного актера
Определенные для системы прецеденты являются фундаментом для всего процесса разработки
© 2005, |
В.В.Хашковский, Д.П.Калачев. |
24 |
© 2004, |
Л.Б.Новиков |
|
Лучший опыт: Управление требованиями
Участие прецедентов в основных дисциплинах разработки
© 2005, |
В.В.Хашковский, Д.П.Калачев. |
25 |
© 2004, |
Л.Б.Новиков |
|
Лучший опыт: Управление требованиями
Типы требований соответствуют различным уровням абстракции и целям представления требований
Примеры: требование возможности, требование тестирования и т.д.
Каждый тип требования должен иметь уникальный набор
атрибутов, связанных с требованиями, определенными на этом уровне
Примеры: приоритет, сложность, номер итерации реализации
© 2005, |
В.В.Хашковский, Д.П.Калачев. |
26 |
© 2004, |
Л.Б.Новиков |
|
Лучший опыт: Управление требованиями
Трассируемость требований позволяет:
Определять источники требований
Управлять контекстом проекта
Управлять
изменениями
требований
Оценивать
последствия от изменения требования
© 2005, |
В.В.Хашковский, Д.П.Калачев. |
27 |
© 2004, |
Л.Б.Новиков |
|
Лучший опыт
Итерационная
разработка
Управление
требованиями
Использование
компонентной Лучший опыт архитектуры
Визуальное
моделирование
Контроль
качества
Управление
изменениями
© 2005, |
В.В.Хашковский, Д.П.Калачев. |
28 |
© 2004, |
Л.Б.Новиков |
|
Лучший опыт: Использование компонентной архитектуры
Архитектура – это совокупность существенных решений относительно:
Организации системы
Структурных элементов и их интерфейсов
Поведения элементов в кооперациях с другими элементами
Составления из элементов все более крупных подсистем
Архитектурного стиля (статические и динамические элементы, интерфейсы, способы интеграции и т.д.)
© 2005, |
В.В.Хашковский, Д.П.Калачев. |
29 |
© 2004, |
Л.Б.Новиков |
|
Лучший опыт: Использование компонентной архитектуры
Каждый специалист видит архитектуру системы со своей точки зрения
Это позволяет сосредоточиться на определенных
аспектах разработки
Представления
взаимодействуют
Общая модель (UML) позволяет отобразить эти взаимодействия
© 2005, |
В.В.Хашковский, Д.П.Калачев. |
30 |
© 2004, |
Л.Б.Новиков |
|