Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 2
Текст из файла (страница 2)
Прецеденты системы НО1.1$ Заключение Обыгрывание ролей Как играть роль Методы, аизлогичпыс обыгрыванию ролей Сценарный просмотр СКС-карточки (С!азз-Ксзропз!Ы!!!у-Со!!аЬогаг!оп, класс-обязанность-взаимодействие) Заключение Создание прототипов Виды прототипов 1! рототицы требований Что прототипировать Построение прототш!а Опенка результатов Заключение тупеть 3. Определение системы Организация информации о требованиях Оргюшзация требований к сложным аппаратным и программным системам Организация требований к семействам продуктов "1)улущпс" требования Олич не бизнес-требований и требований маркетинга Документ концепция Компоненты документа-кош!ешгни Документ !Ус!щ Нй!оп Документ-концепция версии 1,0 Доютчспт-концепция версии 2.0 Документ 1ус!! а Н!з)оп лля уже существующей системы И 14 14 И 14 Рб 15 15 15 15 1з 15 15 1з 16 16 16 16 16 17 17 17 !7 17 17 17 17 18 18 18 18 Содержание 188 183 186 188 18 Часть 4.
Управление масштабом 19 Проблема масштаба проекта Составляющие масштаба проекта 1 рудный вопрос Задаиие масштаба проекта Базовым уровень требований Установка приоритетов Оценка з р)дозатрат Добавлсцис злсмсита риска Сокращение масштаоа Обосиоваииая первая оценка Рабоч и й и ри мер Умение обращаться с заказчиком Привлечение заказчиков к уиравлеии>о масштабом их ир Сообщение о результате Переговоры с заказчиком Управление базовым уровнем Официалыюс измсисиис ! 1еофициальиое изменение Управление масштабом и модели процесса разработ программного обеспечения "Модель водопада" Сииральиая модель Итеративный подход Фазы жизиениого цикла Итерации 1'а>н> ии процессы Что делать, что делать...
193 193 196 20 197 197 198 199 200 201 202 203 21 22 209 209 210 210 211 212 212 оскта 2И 216 217 218 218 219 220 Часть Б. Уточнение определения системы Требоваиия к программному обеспечению Определение требований к программному обссвсчсишо Взаимосвязь между фуикциял>и и трсбоваиинчи к программному обссис >синю Днлсл>л>а требований: что или как Исключение ии>1>ормации, связшии>й с управлением проектом Исклк>че>шс шн)>орл>ацли>, о пик нщсйся к просктиро>шиию 1>ольше в>шмаицн треб>оваиинм, а ис иросктироваишо Итерационный цикл разработки трсбокшшй и проектировании >9Г> 228 229 »>9 230 231 939 Лидер продукта Роль лидера продукта Лидер продукта в среде программных продуктов Лидер продукта в отделе и>г>)юрл>ациоииых технологий и систем (15 / ГГ) Содержание 233 233 234 238 240 241 242 242 254 256 256 2э8 260 26 261 261 264 26э 266 267 267 268 269 269 271 272 Дальнейшая характеристика требований Футгкциональные требования к программному обеспечению Нефункциональные программные требования Ограничения проектирования Являются ли ограничения проектирования истинными требованиями? Испольювание "дочерних" требований для повышения уровня конкретизации Организация дочерних требований Далее...
Уточнение прецедентов Вопросы, на которые нужно ответить Когда следует использовать методологию прецедентов Когда прецеденты не являются наилучшим вариантом Проблема избыточности Совершенствование спецификаций прецедентов Эволюция прецедентов Какие действия включить в прецедент Рабочий пример. Строение простого прецедента Определение акторов Дать название прецеденту Составление краткого описания Определение потока событий Выявление пред- и постусловий Далее... Спецификация требований к программному обеспечению (Мог)егп бо11маге Ке9н)гешепГв брес111са11оп) Пакет спецификаций требований к программному обеспечению (Модегп Звал 1'ас)сабе) Кто отвечает за Модегп 3И3 Расйабе Организация пакета Могшего 383 Рас)сабе Документирование функциональных требований Далее...
Неоднозначность и уровень конкретизации Нахождение "золотой середины ' Пример неоднозначности. У Мери был маленький бара~век Как избежать неоднозначности г1то дслап? Критерии качества требований к программному обеспечению Девять показателей качества Коррсктныс требования 11едвус мысленные требования Полнота набора требований Непротиворечивость набора требований Упорядоченно требований по их важности и стабильности 243 244 244 244 245 24э 247 247 248 248 248 249 249 251 252 Содержание 273 274 274 275 276 276 278 278 278 279 280 280 Проверяемые требования Модифицируемый набор требований Трассируемые требования Понимаемые требования Показатели качества для модели прецедентов Спецификации прецедентов Акторы прецедента Критерии качества пакета Мос1егп ЯВЗ Рас1габе Хорошо составленное оглавление Хороший индекс История исправлений Глоссарий Теоретически обоснованные формальные спецификации требований Псевдокод Конечные автоматы Таблицы решений Графические деревья решений Диаграммы деятельности Модели сущность.связь Объектно.ориентированныс модели Схегяы потоков данных Ведение спецификаций Рабочий пример методы 281 282 283 284 285 285 о86 287 288 289 290 Часть Б.
Построение правильной системы 293 Как правильно постронзь "правильную" систему: общие положения 29 295 296 296 297 297 298 298 299 299 Проверка того, что разработка находится на правильном пути Принципы верификации программного обеспечения Затраты на верификацию Верификация на всех уровнях Доводы в пользу верификации Проверка корректности результатов разработки Обработка изменений, возпикаюших в процессе разработки Далее...
301 301 302 303 304 304 304 307 308 30 код От понимания требований к реализации системы Отображение требований в технический проект и программный Проблема ортогопальностн Объектно-ориентированный подход 11рсцсдент в роли требования Осушествлснне перехода Моделирование систем програмлщого обеспечения 1'оль модели прецедентов в архитектуре 1'еалнзацня прецедентов в модели проектирования 14 Содержание Структурная и поведенческая части коопераций Использование коопераций для реализации наборов отдельных требований От проектирования к реализации Заключение Далее... 31 Использование трассировки для поддержки верификации Роль трассировки при верификации требований Неявная и явная трассировка Дополнительные возможности, предоставляемые трассировкой Использование автоматических средств трассировки Поддержка отношений трассировки Работа без автоматических средств трассировки П ропугденпые отношения "Лишние" отношения Размышления о верификации н трассировке Далее...
32 Проверка правильности системы 11роверка правильности Приемо-сдаточные испытания Тестирование с целью проверки правильности Трассировка при проверке правильности Основанное на требованиях тестирование 1'абочий пример. Тестирование прецедентов Описание тестового примера 1 Трассировка тестовых примеров Тестирование дискретных требований Пропущенные отношения проверки правильности "Лишние*' отношения проверки правильности Тестирование ограничений проектирования Далее... ЗЗ Применение метода анализа дивидендов для определения объема У8сУ-действий Глубина и покрытие ГлубинаУ8сУ У8сУ-покрытие Что подвергать верификации и проверке правильности Вариант 1.
Верифнцировать и проверять правильность всех элементов Вариант 2. Анализ рисков для определения необходимости У8сУ диализ рисков и анализ дивидендов (КО1) Далее... 34 Управление изменениями Почекгу изменяются требования 308 310 310 311 311 313 313 314 316 316 318 320 321 322 323 323 325 326 326 326 327 327 328 328 330 330 331 332 333 334 335 336 336 337 337 337 338 339 340 341 341 Содержание 13 Внешние факторы Внутренние факторы Наш враг — мы сами Процесс управления изменениями Шаг 1. Осознать, что изменения неизбежны, и разработать план управления изменениями Шаг 2. Формирование базового уровня требований Шаг 3. Задание единого канала контроля изменений Шаг 4.
Использование системы контроля изменений для их фиксации Шаг 5. Иерархическое управление изменениями Управление конфигурацией требований Управление изменениями при поддержке программных средств Элементы, иа которые воздействует иэл|енсние Контрольныйжурнал изменений Управление конфигурацией и управление изменениями Заключение 35 С чего начать Посвящение Чему мы научились Введение 11абор приемов 1. Лнализ проблемы Набор приемов 2. Понимание потребностей пользователей Набор приемов 3.
Определение системы Набор приемов 4. Управление масштабом Набор приемов 5. Уточнение определения системы Набор приемов 6. Построение правильной системы Рецепт работы с требованиями Упрощающие предположения Рецепт Теперь — к следующей версии! Приложения Приложение А.
Артефакты системы НОЕ1$ Предварительная информация для рабочего примера Компания 1.ипэепаг!опэ, $.Ы. Команда разработчиков программного обеспечения НО1.13 Набор приемов 1. Лналиэ проблемы Постановка существующей в компании Ьпшепапопз проблемы Блок-схема системы с указанием акторов Описание акторов Описание других заинтересованных лиц Налагаемые на рещение ограничения Набор прнсмов 2. Понимание потребностеи пользователя 341 342 343 344 344 34з 346 346 348 330 332 Зз2 364 Зз4 Збз 359 369 339 369 360 361 361 362 363 363 364 364 364 367 369 371 371 371 371 373 373 374 373 376 376 377 16 Содержание Краткий обзор потребностей пользователей, выявленных с помощью интервью Совещание по вопросу требований к системе НО1.13 2000 Краткое описание модели прецедентов системного уровня системы НО1,13 Набор приемов 3.
Определение системы Органиэация требований к системе НО1.15 Документ-концепция (Ун!оп 1УосшпепО системы НО1.13 Набор приемов 4. Управление масштабом Набор приемов з. Уточнение определения системы Образец описания прецедента системы НО1.13: Управление освещением Спецификация требований к программному обеспечению подсистемы "Центральный блок управления" системы НОЕ1$ Набор приемов б.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
