Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 17

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 17)

Поиск требованийАтрибутСемантикаRisk (риск)Риск, связанный с добавлением этой возможности: High(высокий), Medium (средний) или Low (низкий).Stability(стабильность)Оценка вероятности того, что по какимто причинам требование будет изменено: High (высокая), Medium (средняя)или Low (низкая).TargetReleaseВерсия продукта, в которой требование должно быть реали(целевая версия) зовано.3.7. Поиск требованийТребования следуют из контекста моделируемой системы. В этот контекст входят:• непосредственные пользователи системы;• другие заинтересованные стороны (например, руководители, специалисты обслуживания, установщики);• другие системы, с которыми взаимодействует данная система;• аппаратные устройства, с которыми взаимодействует данная система;• правовые и регулирующие ограничения;• технические ограничения;• коммерческие цели.Как правило, выработка требований начинается с документа, описывающего в общих чертах (vision) то, что собирается делать системаи какие услуги она будет предоставлять ряду заинтересованных сторон.

Назначение этого документа – обозначить наиболее важные целисистемы с точки зрения заинтересованных сторон. Общее описание составляется системным аналитиком в UPфазе Начало.После общего описания системы начинается настоящая выработка требований. В следующих разделах мы обсудим некоторые методики выявления требований.3.7.1. Выяснение требований — карта местностиеще не территорияТри фильтра – пропуск, искажение и обобщение – формируют естественный язык.При выяснении у людей требований, предъявляемых к программнойсистеме, вы всегда пытаетесь добиться от них точной картины, иликарты, модели их сферы деятельности. Согласно книге Ноама Хомского (Noam Chomsky) «Syntactic Structures» [Chomsky 1], опубликованной в 1975 г.

и посвященной трансформационной грамматике, подоб84Глава 3. Рабочий поток определения требованийная карта создается тремя процессами: пропуск (deletion), искажение(distortion) и обобщение (generalization). Эти процессы абсолютно необходимы, поскольку мы просто не располагаем механизмом познания, способным фиксировать каждый нюанс и деталь нашей сферыдеятельности в некоторой воображаемой, подробной до мельчайшихдеталей карте. Поэтому приходится быть изобретательными. Мы осуществляем «выборку» из огромного массива возможной информации,применяя три фильтра:• пропуск – информация отфильтровывается;• искажение – информация изменяется взаимосвязанными механизмами вымысла и представления;• обобщение – информация обобщается в правила, убеждения и понятия об истинности и ложности.Эти фильтры образуют естественный язык. О них важно знать притщательном сборе и анализе требований, поскольку для восстановления информации может понадобиться активно их идентифицироватьи ставить под сомнение.Ниже приведены примеры из системы управления библиотекой.

Длякаждого примера указаны вопрос, соответствующий данному фильтру, и возможный ответ:• Пример: «Они используют систему для получения книг на время» –пропуск.Вопрос: Кто именно использует систему для получения книг на время?Ответ: читатели, другие библиотеки и библиотекари.• Пример: «Тот, кто имеет книгу на руках, не может взять другуюкнигу до тех пор, пока не вернет предыдущую, срок возврата которой истек» – искажение.Вопрос: Существуют ли такие обстоятельства, при которых ктолибо мог бы взять новую книгу до того, как будут возвращены всеимеющиеся на руках книги, срок возврата которых истек?Ответ: Фактически существует два обстоятельства, при которыхправо читателя на получение книг может быть восстановлено.

Вопервых, все имеющиеся на руках книги, срок возврата которых истек, возвращены; вовторых, за все невозвращенные книги, сроквозврата которых истек, внесена плата.• Пример: «Для получения книг у всех должен быть формуляр» –обобщение.Вопрос: Есть ли пользователи системы, которым не обязательноиметь формуляр?Ответ: Некоторые пользователи системы, например другие библиотеки, могут не иметь формуляра или имеют специальный формуляр с другими сроками и условиями возврата книг.853.7. Поиск требованийДва последних случая особенно интересны как примеры общеязыкового шаблона – квантора общности. Примеры кванторов общности:•••всекаждыйвсегда•••никогданиктонисколькоПри встрече с квантором общности всегда можно найти пропуск, искажение или обобщение.

Кванторы общности обычно свидетельствуюто достижении границ или пределов ментальной карты субъекта. Обычно при проведении анализа следует ставить под сомнение кванторыобщности. Чуть не написали «всегда следует ставить под сомнениекванторы общности», но тогда мы бы опровергали самих себя!3.7.2. ИнтервьюПроведение интервью с заинтересованными сторонами является самым прямым способом сбора требований.

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

Этоединственная возможность выяснить, что им нужно на самом деле.• Задавайте контекстносвободные вопросы – вопросы, которые непредполагают какоголибо конкретного ответа и заставляют интервьюируемого говорить о проблеме. Например, вопрос «Кто использует систему?» является контекстносвободным и способствует обсуждению, тогда как вопрос «Систему используете вы?» предполагает ответ «Да/нет» и заканчивает дискуссию.• Слушать – единственный способ выяснить, чего хотят заинтересованные стороны, поэтому дайте им возможность поговорить. Позвольте им обсудить вопрос и рассмотреть его посвоему.

Если выожидаете конкретных ответов на вопросы, у вас, возможно, сформировалось неверное решение и исходя из этого заблуждения вы задаете закрытые вопросы.• Не занимайтесь телепатией. В сущности, мы все в некоторой степени телепаты. Телепатия – это заблуждение по поводу того, что вамизвестны чьито чувства, желания или мысли, базирующееся натом, что вы чувствовали бы, желали бы или думали бы в подобнойситуации. Это важная человеческая способность, потому что онаявляется основой сочувствия. Однако это может внести субъективность в процесс выяснения требований, и все закончится тем, чтовы хотите, а не в чем нуждаются заинтересованные стороны.• Запаситесь терпением!86Глава 3.

Рабочий поток определения требованийОбстановка, в которой проводится интервью, может оказывать большое влияние на качество получаемой информации. В частности, мыпредпочитаем неформальную обстановку, например небольшое кафе,потому что здесь и интервьюер, и интервьюируемый могут расслабиться и разоткровенничаться.Лучший способ записи информации во время интервью – бумага и ручка! Использование портативного компьютера отвлекает обе стороныи может напугать интервьюируемого.

Мы предпочитаем графическиедиаграммы, выражающие идеи, как гибкий, не внушающий страхаи графически богатый способ сбора информации. Более подробно об этомможно узнать по адресу www.mind+map.com.После интервью информация анализируется и формируются некоторые предварительные требования.3.7.3.

АнкетыАнкеты не заменяют интервью.Если принято решение использовать анкеты без проведения интервью,можно оказаться в безвыходной ситуации, когда необходимо выбратьсписок вопросов до того, как стало известно, какие вопросы задавать.Анкеты могут быть полезным дополнением к интервью. Они хорошоподходят для получения ответов на конкретные закрытые вопросы.Можно выделить из интервью ключевые вопросы, объединить ихв анкету, а затем распространить ее на более широкую аудиторию. Этопоможет проверить, правильно ли вы понимаете требования.3.7.4. Семинар по определению требованийСеминар – это один из самых эффективных способов сбора информации, относящейся к требованиям. Для выявления ключевых требований организуется семинар и основные заинтересованные стороны приглашаются принять в нем участие.Семинар должен сосредотачиваться на мозговой атаке.

Это мощнаятехника сбора информации.Во встрече должны принимать участие руководитель проекта, разработчик требований, основные заинтересованные стороны и специалисты в определенной области. Процедура проведения подобного семинара следующая:1. Объясните, что сбор требований проводится методом мозговой атаки.1.1. Все идеи принимаются как хорошие.1.2. Идеи записываются, но не обсуждаются – никогда ни о чем неспорьте, просто записывайте и двигайтесь дальше. Все будетпроанализировано позже.2.

Попросите членов команды назвать ключевые требования к системе.3.8. Что мы узнали872.1. Напишите каждое требование на стикере.2.2. Приклейте стикер на стену или доску.3. Затем можно еще раз просмотреть все выявленные требования и напротив каждого записать дополнительные атрибуты (см. раздел3.6.5).После встречи результаты анализируются и превращаются в требования, как обсуждалось ранее в этой главе. Результаты распространяются для сбора комментариев.Выработка требований – это итеративный процесс, в котором требования выявляются по мере уточнения понимания нужд заинтересованных сторон.

Возможно, придется организовать несколько семинаровпо мере углубления вашего понимания.Намного больше информации об организации семинаров и выработкетребований можно найти в книгах [Leffingwell 1] и [Alexander 1].3.8. Что мы узналиВ данной главе представлен рабочий поток определения требованийв UP и общее обсуждение требований, предъявляемых к программному обеспечению. Вы узнали следующее.• Большая часть работы в рабочем потоке определения требованийвыполняется в фазах Начало и Уточнение жизненного цикла проекта UP.• Наша метамодель требований (рис.

Характеристики

Список файлов книги