Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 55
Текст из файла (страница 55)
Итак. мы будем предполагать, что набор требований образует лпкшл информации. Поэтому иа рис. 2э.! изображены ие только элемеиты этого пакета, ио и их связи. Пакет Мог!егп ЯКБ Рас)сабе — это ие тол~ заморожеииой информации, создапиый в соответствии с требованиями 18О 9000, который затем положат иа полку при продолжении проекта.
Это активный "живой" пакет, во многих случаях играющий чрсзвычайио важную роль при переходе к реализации. ° Ои служит основой для общсиия между всеь~и сторонами-участниками: между са. мими разработчиками, между разработчиками и внешними группами, пользовате. лами и др)тими заинтересованными лицами. ° Формально пли неформально, ои представляет соглашение между этими различ. ными сторонами: если чего-то иет в пакете, разработ.чики ие должны пад этим ра.
ботать. Л если это в пакете есть, опи отвечают за то, чтобы предоставить даин)ю фупкцпоиальиую возможность. Глава 2б. Спецификация требований к программному обеспечению... 2бб Потребности пользователей Документ-концепция Проциммнме требования Требования проектрования/тестираваан/документирования ция и материалы юнвчното пользователя, а таске учебные материалм Модель проектирования Модель тестирования Рис. 35.1. Элементы МтУкгн БВЯ Рпсбаяе ° Он служит в качестве справочника стандартов для администратора програмьтного изделия. Скорее всего, у него не хватит времени, чтобы читать созданный разработчиками код н сравнивать его непосредственно с документом-концепцией; он должен использовать данный пакет в качестве стандарта нри обсуждении вопросов с командой разработчиков.
° Как уже отмечалось ранее, пакет служит исходной информацией для групп, выполняющих проектирование н реализацию. В зависимости от того, как организован проект, люди, занимающиеся реализацией, могли ранее привлекаться к дейст. виям по анализу проблемы и определению функций, что привело к созданию дс» кумента-концепции. Но им нужен именно МотТегп Бйб РасЕаке, чтобы привить решение о том, что должен делать нх код. ° Мобегп ЯЮ Расйабе служит исходной информацией также для групп, выполняющих тестирование и гаратттнрующнх качество (ЯА).
Эти группы также следует привлекать к определенным действиям на более ранних этапах. и им, безусловно, нужно понимать концепцию, лежащую в основе Чтвтоп-докуьтеттта. Но пх основная задача — создать тестовые примеры н ьблопроцедуры, чтооы гарантировать, что разработанная система действительно выполняет отраженные в Модегп ЬКБ Расйабе требования.
Пакет служит в качестве стандарта прн планировании и выполнении тестов. 256 '1асть 5. Уточнение определения системы ° Модегп Бйз Рас)саяе управляет развитием системы на фазе построения; когда функции документа-концепции модифицируются илн когда в него добавляются новые функции, они детализируются в данном пакете. Кто отвечает за Модегп БКЗ Раскладе На самом деле ие так уж важно, кто пишет пакет.
Гораздо важнее, чтобы Модегп 535 Рас)саяе существовал и являлся основой для предстоящих действий по построению и тестированию. Возникает естественный вопрос: кто оямгчаеж эа создание и яоддг)>жну компонентов Мог1ггя Яьз Рос)шу? Обычно члены команды разработчиков самостоятельно берут на себя зту задачу. Команда разработчиков кровно заинтересована в полном понимании паке. та и всех его требований и, владея им, может соответствующим образом влиять на многие систелшые решения.
В конечном итоге, кто может лучше написать требования к программному обеспечения, чем люди, которые затем будут отвечать за соответствие им? '1асто за зту задачу (в качестве детальной доработки документа-концепции) берется системный аналитик, в других случаях тестологи работают рука об руку с командой проекта и берут на себя ответственность за требования. Каждый подход имеет свои плюсы и минусы, и каждая команда сама будет решать, какая стратегия наилу шгая.
Из опыта следует, что если к пакету относиться серьезно, не так важно, кто его написал, хотя и есть некоторая разница в том, отвечает ли эа него ру. ководство или команда. Действительно важно то, что Модегп ЯНБ РасЕаке существует и является основой для дальнейших действий по разработке н тестированию. Конечно, авторы зйБ ие пишут требования в вакууме. Мы обнаружили, что пересмотр данного пакета — наиболее эффективный шаг, позволяющий убедиться, что разработчики, маркетологи, пользователи и другие участники "поют под одну и ту же музыку". Модегп ЯКБ Рас)саке — "живой" артефакт, который нуждается в обновлениях по мере того, как развивае~ся проект и становятся более понятными различные функции. Никогда нг омдугяг дояускагяь, чтобы написанный пакет впоследствии игнорировался.
Организация пакета Мослегп ЯчЯ Раскладе Для болыяой системы пакет Модегп БКБ Рас)саке может быть весьма объемным. Оя может состоять иэ сотен страниц текста и диаграмм прецедентов, а также содержать множество детальной ыи<1юрмации, которой разработчики должны уделить пристальное внимание. Но если пакет правильно написан я хороню организован, его размеры ие будут помехой при использовании; они только будут свидетельствовать об относительной сложности ~В создаваемой системы.
Итак, возникает вопрос: кок саг)угю оргонизовать пакгясз Например, если в колшнду приходит новый разработчик и получает задание работать иад функцией )Г17„ где еыу искать детальное описание этой функции? Или предположиы, что администратор проекта уходит в самый разгар работы; как новый администратор может быстро войти в ко дела и вникнуть в детали управления текущей деятельностью команды проекта? Глава 25. Спецификация требонаний к программному обеспечению...
257 Понятно, что структура пакета должна отвечать природе приложения и организации. Пакет для разработки текстового процессора в компании по производству программного обеспечения в Силиконовой долине, вероятно, будет несколько отличаться от аналогичного пакета для системы управления ааиаполетами. Нас волнует не то, сможет ли эксперт по управлению полетами посетить программистскую фирму в Силиконовой долине и объяснить.
что в действительности означают его ба. Нас заботит, чтобы разработчики и пользователи внутри конкретной органиэации могли объяснить смысл созданных ЬК8, чтобы их пакет оставался актуальным на протяжении всей разработки, а также при со провождении системы после того, как она поступит в производство. Если организация желает при аттестации достичь более высокого уровня по шкале ЯЕ1- СММ иаи получить сертификат БО 9000, она более заинтересована в стандартизации орта. ниэацин и формата своего пакета. Даже без оглядки на СММ и БО, ранее приведенные примеры иллюстрируют вьподы стандартизации: возможность быстрее вникнуть, когда имеется текучесть кадров или в команду приходит новый человек, Она также позволяет гарантиро.
вать, что важнейшая информация не потеряется и все будут знать, где ее искать. Следует помнить, что пакет Модегп ЯЮ Рас2абе не предназначен для того, чтобы его читали как роман от начала до конца. Это скорее справочник, и каждый разработчик будет, как правило, просматривать только необходимые ему разделы. Таким обрюом, нужно так организовать БКБ, чтобы можно было легко и просто находить нужную информацию. Пакет должен подчиняться некой организационной концепции. Мы пришли к выво. ду, что следуюШая организационная схема неплохо подходит практически для всех типов проектов. Эта схема вместе с комментариями, поясняющими некоторые детали структу ры, приводится в приложении В.
Общая информация Исторняпересмотров Содержание 1. Введение 1.1. Цель 1.2. Масштаб 1 8. Ссылки 1.4. Предположения и зависимости 2. Краткая характеристика модели прецедентов 3. Краткая характеристика акторов 4. Требования 4.1. Функциональные требования 4.2. Нефункциональные требования 4.2.1. Практичность 4.2.2. Надежность 4.2.$. Производительность 4.2.4. Возможность сопровождения з. Требования к интерактивной пользовательской документапэги и системе подсказок б. Ограничения проектирования 7. Закупаемые компоненты 8.
Интерфейсы 8.1. Пользовательские интерфейсы 258 Часть 5. Уточнение определении системы 8.2. Аппаратные интерфейсы 8.3. Программные иктерфейсы 8.4. Коммуникационные интерфейсы 9. Требования лицензирования 10. Примечания об авторских правах и т.п. 11. Применяемые стандарты Индекс Глоссарий Приложение. Спецификации прецедентов История пересмотров прецедента Название прецедента Краткое описание Потоки событий Основной поток Альтернативные потоки Первый альтернативный поток Второй альтернативный поток Специальные требования Первое специальное требование Второе специальное требование Предусловия Предусловие 1 Постусловия Постусловие 1 Точки расширения Название точки расширения Другие материалы прецедента Документирование функциональных требований Итак, рассмотрим, чего мы достигли. и Мы пришли к решению, что документацию системных требований следует орта.
иизовать в виде пакета артефактов. ° Эти артефакты могут состоять из текстовых документов, таблиц, схем, прецеден- тов и других элементов, помогающих разработчикам помять, что хочет клиент. ° Мы создали шаблон структуры пакета Мобепг ЯЮ Рас1щбе. Данный шаблон поэзо. лиг организовать и распределить по категориям различные алементы, но основное внимание в нем уделяется эмксаювмм элементам (таким, как спецификации на Глава 2$, Спецификация требований к программному обеспечению... 2$9 естественном языке отдельных требований) и элементам в виде я)мууедеянюе (представление которых включает в себя графическую модель прецедентов и нх текстовые описания). Для сбора требований можно применить как традиционные методы спецификации требований, так и метод прецедентов.
Каждый нз этих методов сам по себе использовался в тысячах успешных проеатов. Но как оптимизировать ныяу работу? Какой метод следует применить в каждом конкретном случае? Что касается спецификации функциональных требований к системе, мы пришли к выводу, что наилучшим подходом является совместное использование моделирования прецедентов и традищеонных спецификаций требований. Рассмотрим "баланс требований", представленный на рис. 25.2. Модвлнроввние прецедентов Трвднцнонные спвцнфнквцнн Хврвктврнстнкн комвнды ° Хороню впвдвет традиционными методами ° Мало энвкоыв с маделнраввннвм Хвризернстмкн команды ° Знвчнтепьныд Опыт в модмироввннн В Опыт рвботы с сбънпно тфивнтираввнны ми мягалагнпмн Отметим, что существует множеснмо возможных вариантов. Некоторые проекты харатггеризуются незначительным числом (или полным отсутствием) спецификаций, кото.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
