Файл: Инфрам.pdf

168 управление областью применения проекта; управление изменениями требований; определение влияния на проект изменения требований; определение влияния отказов и сбоев при тестировании требований; подтверждение правильности определения требований к системе; подтверждение того, что система поддерживает только те функции, которые были запланированы.
Трассировка позволит оценить стоимость требуемых изменений, что очень важно.
IBM Rational RequisitePro позволяет снизить трудоемкость процесса и повысить качество управления требованиями. Этот инструмент позво- ляет фиксировать различные типы требований, формировать для них необходимые атрибуты, осуществлять их структуризацию и трассиров- ку. В RequisitePro требования хранятся в базе данных. Для каждого тре- бования хранится полная история его изменений и расширяемый набор атрибутов. RequisitePro предоставляет удобный графический интерфейс для ввода требований и работы с ними, который позволяет легко выби- рать и сортировать требования по различным критериям.
RequisitePro позволяет легко выбирать требования из текстовых до- кументов (в формате MS Word). Выделение требований из текста доку- ментов может производиться вручную или автоматически по структуре документа (например, каждый абзац - требование) или по ключевым словам (только предложения, содержащие слово «должна»). Более того, требования могут храниться в виде текстовых документов. При этом изменения, внесенные в текстовый документ, автоматически воспроиз- водятся в базе данных. При работе с текстовым документом доступен не только текст требований, но и все его атрибуты. Такой способ хранения позволяет использовать требования в качестве составной части доку- ментов произвольной формы.
Тексты таких требований могут редактироваться в базе данных с ис- пользованием графического интерфейса RequisitePro. Эти изменения автоматически переносятся в текст соответствующих документов. До- кументы с требованиями целиком хранятся в базе данных проекта. Од- нако при необходимости они могут быть взяты из базы данных и ис- пользоваться как обычные электронные документы. В них могут вно- ситься новые или редактироваться старые требования. При возвращении документа в базу данных проекта, все изменения автоматически перено- сятся в базу данных требований. RequisitePro предлагает несколько раз- личных представлений для требований в виде матрицы трассировки или дерева трассировки.
При модификации текста требования или других его атрибутов, та- кая структура позволяет легко отследить другие требования, связанные с измененным, и, возможно, также нуждающиеся в изменении.
RequisitePro позволяет использовать для работы с требованиями раз- личные типы документов: описания сценариев использования, нефунк- циональные требования, концепцию (Vision) и другие. При необходи- мости можно создавать собственные типы документов, требований и

169 определять набор атрибутов для описания этих требований (типовыми атрибутами требований являются, например, приоритет, сложность реа- лизации и статус).
Можно, например, разрабатывать шаблоны документов, соответст- вующих требованиям ГОСТ 34 или ГОСТ 19 [3]. RequisitePro поддер- живает групповую работу с требованиями. Разработчики могут быть разбиты на несколько групп, и для каждой группы могут быть назначе- ны различные права на создание, редактирование и просмотр требова- ний. Для хранения требований RequisitePro может использовать различ- ные СУБД в зависимости от объема требований и числа участников раз- работки: MS Access, MS SQL Server или Oracle. Это обеспечивает воз- можность масштабирования от использования RequisitePro в группах из нескольких разработчиков до самых крупных проектов.
Так как отсутствие анализа требований совершенно очевидно приве- дет к неудаче, то возникает вопрос, почему он не всегда проводится?
Анализ требований – это сложная работа. Аналитическая деятельность включает рассудительность, интуицию, способность к обобщению, эв- ристический подход. Очень редко имеется возможность дедуктивного или математического подтверждения. Многие инженеры характеризуют эту работу как невещественную. Если им предоставить выбор, то они подойдут к разработке на основе принципов, строго обоснованных фи- зическими науками и математическими законами, а не на основе анали- за требований, и именно поэтому неизбежно поведут разработку снизу вверх.
Другая причина отказа от анализа требований связана с тем, что этот анализ не является необходимым шагом. Необходимыми являются только разработка и ее продукт. Подобно тестированию, которое вклю- чается только благодаря тому, что программисты делают ошибки, ана- лиз требований включается потому, что он является средством установ- ления целей, для достижения которых все будут работать. Теоретиче- ски, если бы разработчики были достаточно опытны и подготовлены, то для них не требовалось бы установления направления разработки и осуществления контроля над ними. Применение подобных аргументов для сложных программных систем абсурдно. На практике, если человек пропускает формулировку требований и начинает разработку, то снача- ла возникает чувство удивительно быстрого и успешного продвижения работы, а кончается серьезным разочарованием, за которым следует переработка готового программного продукта.
Анализ требований может быть улучшен за счет глубины изучения субъективных свойств процессов. Существуют две возможности улуч- шения. Первая – количественная оценка процесса, вторая – тестирова- ние требований перед началом разработки. Другая проблема заключает- ся в том, чтобы требования были последовательными и чтобы они по- этапно реализовывались в проекте. Для этого необходима согласован- ность действий разработчиков по этапам проекта.
Улучшение процесса сбора, анализа, документирования, проверки и управления требованиями дает следующие ощутимые преимущества:

170 уменьшение ошибок и издержек при выпуске ПО; повышение удовлетворенности заказчика и качества ПО; уменьшение времени разработки ПО; ужесточение контроля над изменениями; повышение точности планирования; повышение точности стратегического развития комплекса ПО на предприятии; использование требований на разных стадиях разработки ПО; повышение производительности аналитиков и других членов коман- ды; улучшение обмена информацией по проектам; повышение заинтересованности заказчика; вовлечение всей команды в разработку.
4.6. Требования и риски
Анализ требований главным образом имеет отношение к взаимодей- ствию и связи пяти элементов: стоимости, времени, полноты и риска реализации проекта. Взаимодействия между этими элементами образу- ют систему, в которой каждый параметр функционально зависит от дру- гих. Физический смысл этих элементов достаточно прозрачен. Остано- вимся на наиболее важном, который представляет собой ключевую кон- цепцию в разработке программных систем, – это риск [17]. Под риском понимается реально существующий или потенциально возможный фак- тор, обладающий большой вероятностью неблагоприятного влияния на успешное завершение основных этапов проекта. Другими словами, рис- ки – это то, из-за чего проект может завершиться неудачей. Список рис- ков является одним из основных артефактов в технологии RUP.
Всегда есть желание создавать и внедрять полезные программы как можно быстрее. Однако, пытаясь завершить проект быстрее, есть риск, что будет выпущена программа, имеющая много дефектов, чтобы быть полезной. Двигаясь слишком медленно, рискуем, что выпустим про- грамму слишком поздно, и она потеряет актуальность, или не выпустим ее вообще, или заказчик расторгнет контракт (рис. 4.7). Осваивая новую технологию, технику, инструментальные средства, рискуем наделать много ошибок. Не осваивая, рискуем проиграть в конкурентной борьбе.
Представление рисков можно формализовать, например, определять ранг риска (важность), давать описание, стратегию исключения и др.
Список рисков может быть и неформальным. Тем не менее, рекоменду- ется оформить его в письменном виде и хранить в доступном месте, может быть на Web-сайте проекта.

171
Рис. 4.7. Возможные риски в реализации проекта
Чем выше сложность проекта, тем больше рисков при его разработ- ке, и число рисков будет возрастать, если у разработчика не налажен процесс управления требованиями. Следующая диаграмма показывает соотношение числа рисков и сложности проекта с наложенными на них пятью уровнями модели зрелости для управления требованиями
(рис. 4.8). Рассмотрим эти уровни более подробно [4]. Уровень 0 ха- рактеризуется отсутствием требований (хаос). Данный уровень характе- рен для большинства организаций постсоветского пространства, так как ошибочно считается, что главное во всем процессе разработки – это именно программирование (кодирование) разрабатываемой системы.
В данном случае организация делает предположение, что ей все по- нятно и известно для того, чтобы приступить к разработке программной системы, и что благодаря сэкономленному времени на этапе сбора, ана- лиза и документирования требований, в дальнейшем будет возможность уделять больше внимания программированию. Результатом такого под- хода может быть: продукт с пропущенной функциональностью; продукт с никому не нужной функциональностью; продукт низкого качества; проекты никогда не заканчиваются в срок.
Уровень 1. Документирование требований дает сразу неоспоримые преимущества. Во-первых, у разработчика появляются сразу некий до- кумент требований для разговора с заказчиком, в котором описывается, как он поняли его потребности, и, читая данный документ, заказчик со- глашается или не соглашается с тем, что предложил разработчик. Во- вторых, появляется документ требований, который является неким ба- зисом для всех членов команды разработки. Например, проектировщики и архитекторы могут продумать и построить более правильный дизайн системы, а тестировщики будут иметь эталон для тестирования разрабо- танной функциональности. В-третьих, документ требований может яв- ляться основой для новых людей, которые войдут в проект. Прочитав данный документ, новый человек в команде будет знать, что система должна делать, а это уменьшит риск ошибки нового члена команды.

172
Рис. 4.8. Соотношение рисков и сложности проекта
Начав документировать требования, проектная команда сталкивается с новыми задачами – получить актуальный набор требований к про- граммной системе, не пропустить требования, не выполнять работу дважды и т.д. Эти и другие задачи решаются на следующих уровнях модели зрелости для управления требованиями.
Уровень 2. Организация требований. Данный уровень модели зрело- сти для управления требованиями уже говорит о качестве требований – их формате, сохранности и версионности. Качественные требования понятны как заказчику, который их формирует, так и всем членам про- ектной команды, которые разрабатывают программное обеспечение, удовлетворяющее потребностям заказчика. Для этого требования долж- ны быть не только читаемыми, но и однозначными и непротиворечивы- ми.
Требования должны быть хорошо отформатированы. Сквозная ну- мерация, постоянные схемы, заголовки, шрифты и хорошее оглавление делают ваши документы легкими для прочтения, понимания и дальней- шего использования. Если требования хорошо описаны, но плохо от- форматированы, то документ может стать бесполезным в использова- нии. Форматирование – это простой прием, но почему-то часто игнори- руется. Здесь могут помочь корпоративные или международные шабло- ны спецификаций, такие как концепция (Vision), спецификация требо- ваний (Software Requirement Specification) и др. Причем во всей органи- зации должны применяться единые форматирование и шаблоны.
Писать качественные требования – не простая задача, поэтому руко- водитель должен учить своих аналитиков, организовать процессы про- верки требований более опытными аналитиками, а также им поручить согласования требований с заказчиком.
Уровень 3. Структурирование требований. Третий уровень модели зрелости для управления требованиями концентрируется на атомарно- сти и типах требований: бизнес-требования или системные, функцио- нальные или нефункциональные и т.д. Также данный уровень добавляет необходимую информацию к требованиям, кроме текста.

173
Во-первых, разработчик должен выделять требования как атомар- ные единицы для того, чтобы было легче: понять, что данное требование описывает; ссылаться на конкретное требование, а не на страницу со сплошным текстом; воспринимать изменения требований; разрабатывать и тестировать конкретную функциональность; присваивать атрибуты требованиям.
Во-вторых, необходимо различать разные типы требований. Если все требования идут одним сплошным списком, то, скорее всего, там перемешаны различные уровни их представления (бизнес-требования, пользовательские требования, системные требования), а также виды требований (функциональные, ограничения, бизнес-правила и т.д.). Та- кой документ, с одной стороны, плохо воспринимается заказчиком
(бизнесом), который сосредоточен на формулировании бизнес- требований, а с другой стороны, непонятен для разработчиков, которые реализуют системные требования.
В-третьих, следует добавлять атрибуты к атомарным требованиям, так как на самом деле все требования не равны между собой: одни более важные, чем другие, третьи сложнее реализовать, чем первые и т.д. Не- обходимые атрибуты, добавленные к требованиям, позволяют легче ими управлять: определять их приоритеты; понимать, какие требования описаны, какие разработаны, а какие протестированы, понимать, в какой версии продукта они реализованы, и т.д.
Не следует делать распространенную ошибку – брать все возможные атрибуты из другого проекта. Нужно понять, какие атрибуты необходи- мы, исходя из сложности проекта, требований заказчика, методологии разработки и других условий.
Третий уровень модели зрелости для управления требованиями дает лучшее понимание требований всем участникам проекта и облегчает управление ими. Атрибуты позволяют более четко очертить зону ответ- ственности каждого участника проекта, делать меньше работы по поис- ку нужных требований и уменьшить предположения. Разделение на ти- пы требований также позволяет быть уверенным в том, что аналитики не пропустили необходимую информацию и указали ее в требованиях.
Поскольку типы и атрибуты требований сильно зависят от вида про- екта, должны быть выработаны соглашения перед началом каждого проекта, которые оформляются в документе, называемом План управ- ления требованиями. На данном уровне вам уже будет трудно управлять требованиями с помощью простого текстового редактора (MS Word,
Office Writer и др.). На помощь могут прийти специализированные ин- струменты: IBM Rational RequisitePro и IBM Telelogic Doors.
Даже идеально структурированные и организованные требования могут не дать полной картины потребностей заказчика, потому что 20–
50 страниц текста воспринять очень трудно. На помощь могут прийти

174 разного рода модели, которые позволяют активизировать второе полу- шарие мозга и взглянуть на требования «по-новому».
При изучении и документировании бизнес-требований могут помочь модель объектов предметной области (Business/Domain Object Model), модель бизнес-вариантов использования (Business Use Case Model) или модель бизнес-процессов (Business Process Model). При более детальном изучении потребностей заказчика (пользовательских требований) помо- гут модель системных вариантов использования (Use Case Model), диа- граммы действий, состояний и взаимодействия. Естественно, нельзя увлекаться только текстовым или только модельным представлением требований. Нужно их комбинировать, четко осознавая, где лучше при- менить текст и (или) модели для представления информации.
Уровень 4. Трассировка требований. Реализация предыдущих трех уровней модели зрелости для управления требованиями не дает воз- можности определять и прослеживать взаимосвязь между требования- ми. Система любой сложности должна иметь иерархичность требова- ний. Например, в RUP иерархия требований прослеживается между бизнес-потребностями, характеристиками программной системы, вари- антами использования и системными требованиями. Возможность от- слеживать данную взаимосвязь обычно называется трассировкой. Трас- сировка дает возможность проследить влияние требований друг на дру- га и провести анализ покрытия требований.
При изменении одного требования аналитику важно знать, какие еще требования должны при этом измениться – это и называется прослежи- ванием влияния требований друг на друга. А после того как описан на- бор требований, необходимо знать, все ли требования верхнего уровня были детализированы и описаны на более низком уровне. Последнее называется «анализ покрытия требований».
Процедуру взаимосвязей и анализ покрытия обычно описывают так- же в Плане управления требованиями. На данном этапе становится оче- видно, что управлять требованиями в полном объеме очень трудно без специализированных средств. Решить эту задачу можно с помощью ин- струментальных средств управления требованиями, таких как: IBM
Rational RequisitePro, IBM Rational ArchitectIBM, IBM Rational
Composer, IBM Telelogic Doors, или IBM Telelogic Focal Point.
Уровень 5. Интеграция требований. Как отмечалось выше, требова- ния служат неким соглашением между тем, что заказчик хочет и тем, что должно делать программное обеспечение. Но до этого момента нельзя было четко проследить связь от потребностей заказчика до кода в программном продукте. На пятом уровне необходимо интегрировать процесс управления требованиями с процессами управления измене- ниями, проектирования, разработки, тестирования и управления проек- том.
Требования служат первичным входом для разработки программной системы. Поэтому архитекторы программной системы должны быть уверены (должны проследить), что все требования реализованы в ди- зайне проекта. А разработчики должны понять, как требования соотно-