UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
Рис. 3.7. Иерархия типов требований 3.6. Определение понятия требования 81 Конкретные типы требований зависят от типа создаваемого программ ного обеспечения. Это особенно касается функциональных требова ний. Для нефункциональных требований набор типов требований, приведенный на рис. 3.7, довольно стандартный и неплох для начала. Организация требований по типам полезна в случае большого числа требований (около сотни и более). Такой подход особенно хорош, если используется инструментальное средство выработки требований. То гда для получения полезной информации можно будет делать запрос к модели требований по типу требований. В принципе глубина иерархии типов требований может быть любой. На практике двух трех уровней для системы средней сложности впол не достаточно. 3.6.5. Атрибуты требований У каждого требования может быть ряд атрибутов, фиксирующих до полнительную информацию (метаданные) о требовании. Каждый атрибут требования имеет описательное имя и значение. На пример, у требования может быть атрибут dueDate (дата платежа), зна чением которого является дата выполнения данного требования. Так же требование может иметь атрибут source (источник), в качестве зна чения которого выступает описание того, откуда возникло данное тре бование. Конкретный набор используемых атрибутов зависит от природы и нужд проекта и может меняться в зависимости от типа тре бования. Наверное, самым распространенным атрибутом требований является priority (приоритет). Его значение определяет приоритет требования от носительно остальных требований. Обычно для назначения приорите тов применяется набор критериев MoSCoW, описанный в табл. 3.1. Таблица 3.1 Если применяется схема MoSCoW, у каждого требования есть атрибут Priority, который может принимать одно из значений: M, S, C или W. Инструментальные средства выработки требований обычно обеспечива ют возможность делать запрос к модели требований по значению атри Значения атрибута Priority Семантика Must have (обязан иметь) Обязательные требования, являющиеся фун даментальными для системы. Should have (должен иметь) Важные требования, которые могут быть опу щены. Could have (мог бы иметь) По настоящему необязательные требования (реализуются, если есть на это время). Want to have (хотел бы иметь) Требования, которые могут подождать до сле дующих версий системы. 82 Глава 3. Рабочий поток определения требований бута. Таким образом, можно, например, сгенерировать список всех тре бований с максимальным приоритетом (Must have). Это очень полезно! Преимущество набора критериев MoSCoW в его простоте. Однако в нем смешиваются два разных свойства требования: важность и очеред ность. Важность требования, единожды заданная, стремится оставать ся относительно стабильной. А вот очередность, оцениваемая относи тельно остальных требований, в ходе проекта может меняться незави симо от важности требования. Например, доступность ресурсов или зависимости от других требований. RUP определяет более полный набор атрибутов требований, в котором разделены важность (Benefit) и очередность (TargetRelease). Атрибу ты RUP представлены в табл. 3.2. Количество атрибутов требований должно быть минимальным, от этого проект только выиграет. Выбор того, что применять – MoSCoW, RUP или какой то другой на бор атрибутов требований, – зависит от конкретного проекта. Главное при определении набора атрибутов – сделать его максимально про стым. Необходимо выбирать только те атрибуты, которые полезны проекту. Если атрибут не приносит пользы, не надо его использовать. Таблица 3.2 Атрибут Семантика Status (статус) Может иметь одно из следующих значений: Proposed (предложенные) – требования, которые находятся в состоянии обсуждения и еще не утверждены. Approved (одобренные) – требования, утвержденные для реализации. Rejected (отклоненные) – требования, которые решено не реализовывать. Incorporated (включенные) – требования, которые были реализованы в определенной версии. Benefit (полезность) Может иметь одно из следующих значений: Critical (критичное) – требование должно быть реализова но, в противном случае система не будет принята заинтере сованными сторонами. Important (важное) – требование может быть опущено, но это неблагоприятно отразится на удобстве использования системы и удовлетворении заинтересованных сторон. Useful (полезное) – требование может быть опущено без су щественного влияния на приемлемость системы. Effort (трудоемкость) Оценка времени и ресурсов, необходимых для реализации возможности, выраженная в человеко часах или другими методами, например методом функциональных точек (www.ifpug.org) 3.7. Поиск требований 83 3.7. Поиск требований Требования следуют из контекста моделируемой системы. В этот кон текст входят: • непосредственные пользователи системы; • другие заинтересованные стороны (например, руководители, спе циалисты обслуживания, установщики); • другие системы, с которыми взаимодействует данная система; • аппаратные устройства, с которыми взаимодействует данная систе ма; • правовые и регулирующие ограничения; • технические ограничения; • коммерческие цели. Как правило, выработка требований начинается с документа, описы вающего в общих чертах (vision) то, что собирается делать система и какие услуги она будет предоставлять ряду заинтересованных сто рон. Назначение этого документа – обозначить наиболее важные цели системы с точки зрения заинтересованных сторон. Общее описание со ставляется системным аналитиком в UP фазе Начало. После общего описания системы начинается настоящая выработка тре бований. В следующих разделах мы обсудим некоторые методики вы явления требований. 3.7.1. Выяснение требований — карта местности еще не территория Три фильтра – пропуск, искажение и обобщение – формируют естест венный язык. При выяснении у людей требований, предъявляемых к программной системе, вы всегда пытаетесь добиться от них точной картины, или карты, модели их сферы деятельности. Согласно книге Ноама Хомско го (Noam Chomsky) «Syntactic Structures» [Chomsky 1], опубликован ной в 1975 г. и посвященной трансформационной грамматике, подоб Risk (риск) Риск, связанный с добавлением этой возможности: High (высокий), Medium (средний) или Low (низкий). Stability (стабильность) Оценка вероятности того, что по каким то причинам требо вание будет изменено: High (высокая), Medium (средняя) или Low (низкая). TargetRelease (целевая версия) Версия продукта, в которой требование должно быть реали зовано. Атрибут Семантика 84 Глава 3. Рабочий поток определения требований ная карта создается тремя процессами: пропуск (deletion), искажение (distortion) и обобщение (generalization). Эти процессы абсолютно не обходимы, поскольку мы просто не располагаем механизмом позна ния, способным фиксировать каждый нюанс и деталь нашей сферы деятельности в некоторой воображаемой, подробной до мельчайших деталей карте. Поэтому приходится быть изобретательными. Мы осу ществляем «выборку» из огромного массива возможной информации, применяя три фильтра: • пропуск – информация отфильтровывается; • искажение – информация изменяется взаимосвязанными механиз мами вымысла и представления; • обобщение – информация обобщается в правила, убеждения и по нятия об истинности и ложности. Эти фильтры образуют естественный язык. О них важно знать при тщательном сборе и анализе требований, поскольку для восстановле ния информации может понадобиться активно их идентифицировать и ставить под сомнение. Ниже приведены примеры из системы управления библиотекой. Для каждого примера указаны вопрос, соответствующий данному фильт ру, и возможный ответ: • Пример: «Они используют систему для получения книг на время» – пропуск. Вопрос: Кто именно использует систему для получения книг на вре мя? Ответ: читатели, другие библиотеки и библиотекари. • Пример: «Тот, кто имеет книгу на руках, не может взять другую книгу до тех пор, пока не вернет предыдущую, срок возврата кото рой истек» – искажение. Вопрос: Существуют ли такие обстоятельства, при которых кто ли бо мог бы взять новую книгу до того, как будут возвращены все имеющиеся на руках книги, срок возврата которых истек? Ответ: Фактически существует два обстоятельства, при которых право читателя на получение книг может быть восстановлено. Во первых, все имеющиеся на руках книги, срок возврата которых ис тек, возвращены; во вторых, за все невозвращенные книги, срок возврата которых истек, внесена плата. • Пример: «Для получения книг у всех должен быть формуляр» – обобщение. Вопрос: Есть ли пользователи системы, которым не обязательно иметь формуляр? Ответ: Некоторые пользователи системы, например другие библио теки, могут не иметь формуляра или имеют специальный форму ляр с другими сроками и условиями возврата книг. 3.7. Поиск требований 85 Два последних случая особенно интересны как примеры общеязыко вого шаблона – квантора общности. Примеры кванторов общности: При встрече с квантором общности всегда можно найти пропуск, иска жение или обобщение. Кванторы общности обычно свидетельствуют о достижении границ или пределов ментальной карты субъекта. Обыч но при проведении анализа следует ставить под сомнение кванторы общности. Чуть не написали «всегда следует ставить под сомнение кванторы общности», но тогда мы бы опровергали самих себя! 3.7.2. Интервью Проведение интервью с заинтересованными сторонами является са мым прямым способом сбора требований. Обычно более полную ин формацию можно получить при интервьюировании один на один. Основные моменты указаны ниже. • Не заблуждайтесь по поводу решения – вам может казаться, что вы очень хорошо понимаете, чего хотят заинтересованные стороны. Но во время интервью это предположение не должно учитываться. Это единственная возможность выяснить, что им нужно на самом деле. • Задавайте контекстно свободные вопросы – вопросы, которые не предполагают какого либо конкретного ответа и заставляют интер вьюируемого говорить о проблеме. Например, вопрос «Кто исполь зует систему?» является контекстно свободным и способствует об суждению, тогда как вопрос «Систему используете вы?» предпола гает ответ «Да/нет» и заканчивает дискуссию. • Слушать – единственный способ выяснить, чего хотят заинтересо ванные стороны, поэтому дайте им возможность поговорить. По звольте им обсудить вопрос и рассмотреть его по своему. Если вы ожидаете конкретных ответов на вопросы, у вас, возможно, сфор мировалось неверное решение и исходя из этого заблуждения вы за даете закрытые вопросы. • Не занимайтесь телепатией. В сущности, мы все в некоторой степе ни телепаты. Телепатия – это заблуждение по поводу того, что вам известны чьи то чувства, желания или мысли, базирующееся на том, что вы чувствовали бы, желали бы или думали бы в подобной ситуации. Это важная человеческая способность, потому что она является основой сочувствия. Однако это может внести субъектив ность в процесс выяснения требований, и все закончится тем, что вы хотите, а не в чем нуждаются заинтересованные стороны. • Запаситесь терпением! • все • никогда • каждый • никто • всегда • нисколько 86 Глава 3. Рабочий поток определения требований Обстановка, в которой проводится интервью, может оказывать боль шое влияние на качество получаемой информации. В частности, мы предпочитаем неформальную обстановку, например небольшое кафе, потому что здесь и интервьюер, и интервьюируемый могут расслабить ся и разоткровенничаться. Лучший способ записи информации во время интервью – бумага и руч ка! Использование портативного компьютера отвлекает обе стороны и может напугать интервьюируемого. Мы предпочитаем графические диаграммы, выражающие идеи, как гибкий, не внушающий страха и графически богатый способ сбора информации. Более подробно об этом можно узнать по адресу www.mind map.com. После интервью информация анализируется и формируются некото рые предварительные требования. 3.7.3. Анкеты Анкеты не заменяют интервью. Если принято решение использовать анкеты без проведения интервью, можно оказаться в безвыходной ситуации, когда необходимо выбрать список вопросов до того, как стало известно, какие вопросы задавать. Анкеты могут быть полезным дополнением к интервью. Они хорошо подходят для получения ответов на конкретные закрытые вопросы. Можно выделить из интервью ключевые вопросы, объединить их в анкету, а затем распространить ее на более широкую аудиторию. Это поможет проверить, правильно ли вы понимаете требования. 3.7.4. Семинар по определению требований Семинар – это один из самых эффективных способов сбора информа ции, относящейся к требованиям. Для выявления ключевых требова ний организуется семинар и основные заинтересованные стороны при глашаются принять в нем участие. Семинар должен сосредотачиваться на мозговой атаке. Это мощная техника сбора информации. Во встрече должны принимать участие руководитель проекта, разра ботчик требований, основные заинтересованные стороны и специали сты в определенной области. Процедура проведения подобного семина ра следующая: 1. Объясните, что сбор требований проводится методом мозговой атаки. 1.1. Все идеи принимаются как хорошие. 1.2. Идеи записываются, но не обсуждаются – никогда ни о чем не спорьте, просто записывайте и двигайтесь дальше. Все будет проанализировано позже. 2. Попросите членов команды назвать ключевые требования к системе. 3.8. Что мы узнали 87 2.1. Напишите каждое требование на стикере. 2.2. Приклейте стикер на стену или доску. 3. Затем можно еще раз просмотреть все выявленные требования и на против каждого записать дополнительные атрибуты (см. раздел 3.6.5). После встречи результаты анализируются и превращаются в требова ния, как обсуждалось ранее в этой главе. Результаты распространяют ся для сбора комментариев. Выработка требований – это итеративный процесс, в котором требова ния выявляются по мере уточнения понимания нужд заинтересован ных сторон. Возможно, придется организовать несколько семинаров по мере углубления вашего понимания. Намного больше информации об организации семинаров и выработке требований можно найти в книгах [Leffingwell 1] и [Alexander 1]. 3.8. Что мы узнали В данной главе представлен рабочий поток определения требований в UP и общее обсуждение требований, предъявляемых к программно му обеспечению. Вы узнали следующее. • Большая часть работы в рабочем потоке определения требований выполняется в фазах Начало и Уточнение жизненного цикла про екта UP. • Наша метамодель требований (рис. 3.3) показывает, что существует два способа представления требований: 1) функциональные и не функциональные требования и 2) прецеденты и актеры. • Детализация рабочего потока определения требований в UP вклю чает следующие деятельности, представляющие интерес для ОО аналитиков и разработчиков: • Выявление актеров и прецедентов; • Детализация прецедента; • Построение модели прецедентов. • Стандартный рабочий поток определения требований в UP расши ряется: • актером: Разработчик требований; • деятельностью: Выявление функциональных требований; • деятельностью: Выявление нефункциональных требований; • деятельностью: Назначение приоритетов требований; • деятельностью: Отображение (trace) требований в прецеденты. • Большинство провалов проектов обусловлено недостатками выра ботки требований. 88 Глава 3. Рабочий поток определения требований • Существует два типа требований: • функциональные требования – какое поведение должна предла гать система; • нефункциональные требования – определенное свойство или ограничение, накладываемое на систему. • Правильно сформированные требования должны быть выражены в простых структурированных фразах на английском языке, исполь зующих выражения shall (должен), для того чтобы инструменталь ные средства выработки требований могли без труда проводить их синтаксический анализ. • Модель требований содержит функциональные и нефункциональ ные требования к системе. Это может быть: • документ; • база данных в системе управления требованиями. • Требования могут быть организованы в таксономию – иерархию ти пов требований, которая классифицирует требования. • Требования могут иметь атрибуты – дополнительную информацию (метаданные), ассоциированную с каждым требованием: • например приоритет – MoSCoW (Must have, Should have, Could have, Want to have); • например атрибуты RUP (Status, Benefit, Effort, Risk, Stability, TargetRelease); • количество атрибутов требований должно быть минимальным, от этого проект только выиграет. • Карта местности еще не территория. Естественный язык содержит: • пропуски – информация отфильтровывается; • искажения – информация модифицируется; • обобщения – информация обобщается в правила, убеждения и по нятия об истинности и ложности. • Кванторы общности (например, «все», «каждый») могут указывать границы чьей либо ментальной карты сферы деятельности; их необ ходимо ставить под сомнение. • Техники выявления требований: • интервью; • анкеты; • семинары. 4 Моделирование прецедентов 4.1. План главы В этой главе обсуждаются основы моделирования прецедентов, что яв ляется еще одной формой выработки требований. Моделирование пре цедентов будет рассмотрено так, как оно описано в UP. Основное вни мание уделяется конкретным методам и стратегиям, которые могут применяться ОО аналитиком или дизайнером для эффективного моде лирования прецедентов. В разделе приведены только самые простые прецеденты, чтобы ничто не отвлекало от рассмотрения этих методов. Полный (и более сложный) учебный пример можно найти на нашем веб сайте www.umlandtheunifiedprocess.com. UML не определяет какой либо формальной структуры для описания прецедентов. В этом кроется проблема, поскольку разные разработчи ки моделей используют разные стандарты. Чтобы как то справиться с этим, в этой главе и в учебном примере мы приняли простой и эффек тивный стандарт. Наш веб сайт предоставляет схему XML (eXtensible Markup Language, расширяемый язык разметки) с открытым исход ным кодом для прецедентов и актеров, которую читатели могут сво бодно использовать в своих проектах. Эти шаблоны основываются на лучших практиках индустрии и обеспечивают простой, но при этом эффективный стандарт записи спецификаций прецедентов. На нашем веб сайте также можно найти очень простую таблицу сти лей XSL (eXtensible Stylesheet Language, расширяемый язык стилей), которая превращает XML документы прецедентов в HTML, отобража емый в броузере. Эта таблица стилей – полезный пример. Она может быть запросто настроена под стандарты фирменного оформления или другие стандарты оформления документов для различных организа ций. Подробное обсуждение XML выходит за рамки нашей книги, но для эффективной работы с такими документами, возможно, понадо бится обратиться к учебникам по XML, таким как [Pitts 1] и [Kay 1]. |