Структурный анализ потоков данных с помощью диаграмм DFD

Так же, как и диаграммы IDEF0, диаграммы потоков данных (Data Flow Diagrams – DFD) моделируют систему как набор действий, соединенных друг с другом стрелками. Диаграммы потоков данных могут содержать два новых типа объектов: объекты, собирающие и хранящие информацию, – хранилища данных и внешние сущности – объекты, моделирующие взаимодействие с теми частями системы (или другими системами), которые выходят за границы моделирования (рис. 3.6.36).

В отличие от стрелок в IDEF0, которые иллюстрируют отношения, стрелки в DFD показывают, как объекты (включая и данные) реально перемещаются от одного действия к другому. Это представление потока обеспечивает отражение в DFD-моделях таких физических характеристик системы, как движение объектов (потоки данных), хранение объектов (хранилища данных), источники и потребители объектов (внешние сущности).

Построение DFD-диаграмм в основном ассоциируется с разработкой программного обеспечения, поскольку нотация DFD изначально была разработана для этих целей. В частности, графическое изображение объектов на DFD-диаграммах этой главы соответствует принятому Крисом Гейном (Chris Gane), Тришем Сарсоном (Irish Sarson) –.авторами DFD-метода, известного как метод Гейна-Сарсона. Другой распространенной нотацией DFD является так называемый метод Йордана-Де Марко (Yourdon-DeMarсo).

В отличие от IDEF0, рассматривающего систему как множество взаимопересекающихся действий, в названиях объектов DFD-диаграмм преобладают имена существительные; Контекстная DFD-диаграмма часто состоит из одного функционального блока и нескольких внешних сущностей. Функциональный блок на этой диаграмме обычно имеет имя, совпадающее с именем всей системы (рис. 3.6.37).

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

Рис. 3.6.37. Контекстная DFD-диаграмма

Функциональный блок DFD моделирует некоторую функцию, которая преобразует сырье в какую-либо продукцию (или, в терминах IDEF, вход в выход). Хотя функциональные блоки DFD и изображаются в виде прямоугольников с закругленными углами, они почти идентичны функциональным блокам IDEF0 и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения, как IDEF0. В некоторых интерпретациях нотации DFD Гейна-Сарсона механизмы исполнения IDEF0 моделируются как ресурсы и изображаются в нижней части прямоугольника (рис. 3.6.38).

Рис. 3.6.38. Элемент DFD-диаграммы, построенной по нотации Гейна - Сарсона

Внешние сущности обеспечивают необходимые входы для системы и/или являются приемниками для ее выходов. Одна внешняя сущность может одновременно предоставлять входы (функционируя как поставщик) и принимать выходы (функционируя как получатель).

Рис. 3.6.36. Пример DFD-диаграммы

Внешние сущности изображаются как отбрасывающие тень прямоугольники (рис. 3.6.39) и обычно размещаются у краев диаграммы. Одна внешняя сущность может повторяться на одной и той же диаграмме несколько раз. Этот прием полезно применять для сокращения количества линий, соединяющих объекты на диаграмме.

Рис. 3.6.39. Обозначение внешней сущности

Стрелки описывают передвижение (поток) объектов от одной части системы к другой. Поскольку все стороны обозначающего функциональный блок DFD прямоугольника равнозначны (в отличие от IDEF0), стрелки могут начинаться и заканчиваться в любой части блока. В DFD также используются двунаправленные стрелки, которые нужны для отображения взаимодействия между блоками (например, диалога типа «приказ–результат выполнения»). На рис. 3.6.40 двунаправленная стрелка обозначает взаимный обмен информацией между департаментом маркетинга и рекламы и департаментом пластиковых карт.

Рис. 3.6.40. Двунаправленный поток между блоком и внешней сущностью

В то время как потоки данных представляют объекты в процессе их передвижения, хранилища данных моделируют их во всех остальных состояниях. При моделировании производственных систем хранилищами данных служат места временного складирования, где хранится продукций на промежуточных стадиях обработки. В информационных системах хранилища данных представляют любой механизм, который поддерживает хранение данных для их промежуточной обработки. На рис. 3.6.41 приведён пример обозначения хранилищ данных на DFD-диаграммах.

Рис. 3.6.41. Обозначение хранилища данных на DFD-диаграмме

Стрелки на DFD-диаграммах могут быть разбиты (разветвлены) на части, и при этом каждый получившийся сегмент может быть переименован таким образом, чтобы показать декомпозицию данных, переносимых конкретным потоком (рис. 3.6.42).

Стрелки могут соединяться между собой(объединяться) для формирования так называемых комплексных объектов. Пример такого объединения приведен на рис. 3.6.43.

Диаграммы DFD можно строить с использованием подхода, аналогичного структурному методу анализа и проектирования, применяемому в IDEF0. Вначале строится модель физической реализации существующей системы, которая используется пользователями в настоящее время. Затем создается логическая модель для моделирования основных требований реальной, системы. После этого формируется новая логическая модель для отражения основных параметров разрабатываемой системы. И наконец, создается новая физическая модель, реализующая логическую модель новой системы.

Рис. 3.6.42. Разветвление стрелки, иллюстрирующее декомпозицию данных

Рис. 3.6.43. Объединение потоков в один

В настоящее время при разработке информационных систем завоевывает все большую популярность альтернативный подход, известный как разделение событий, в котором для моделирования системы строится несколько моделей DFD. Вначале строится логическая модель, отображающая систему как набор действий и описывающая, что должна делать система.

Затем строится модель окружения, описывающая систему как объект, отвечающий на события, порождаемый внешними сущностями. Такая модель обычно состоит из описания назначения системы, одной диаграммы контекстного уровня и списка событий. Контекстная диаграмма содержит один функциональный блок, представляющий систему в целом, и внешние сущности (окружения), с которыми система взаимодействует.

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

При подготовке такого рода моделей к различным презентациям обычно необходима их «чистка». При этом может применяться как создание упрощенных родительских диаграмм посредством объединения нескольких функциональных блоков в один, так и, наоборот, декомпозиция некоторых элементов для более легкого восприятия модели.

В DFD каждый номер функционального блока может включать в себя префикс, номер родительской диаграммы и собственно номер объекта (рис. 3.6.44). Номер объекта уникальным образом идентифицирует функциональный блок на диаграмме. Номер родительской диаграммы и номер объекта в совокупности обеспечивают уникальную идентификацию каждого блока модели.

Уникальные номера присваиваются также каждому хранилищу данных и каждой внешней сущности вне зависимости от расположения объекта на диаграмме. Каждый номер хранилища данных содержит префикс D (Data Store) и уникальный номер хранилища в модели (например, D3).

Рис. 3.6.44. Компоненты номера функционального блока DFD

Аналогично, номер каждой внешней сущности содержит префикс Е (External entity) и уникальный номер сущности в модели (например, Е5).

Таким образом, диаграммы потоков данных (DFD) обеспечивают удобный способ описания передаваемой информации, как между частями моделируемой системы, так и между системой и внешним миром. Это качество определяет область применения DFD – они используются для создания моделей информационного обмена организации, например модели документооборота. Кроме того, различные вариации DFD широко применяются при построении корпоративных информационных систем.

Лекция 11.

3.3. ОСОБЕННОСТИ РАЗРАБОТКИ ТРЕБОВАНИЙ К ПО (АС)

В разработке требований к программному обеспечению (ПО) заинтересованы различные лица, такие как:

1. заказчики, которые финансируют проект или приобретают продукт для решения каких-то своих задач;

2. пользователи, которые взаимодействуют напрямую или не напрямую с приложениями (подкласс заказчиков);

3. аналитики требований, которые пишут требования и передают их разработчикам;

4. разработчики, которые создают, разворачивают и поддерживают продукт;

5. тестеры, которые определяют соответствие поведения ПО желаемому;

6. технические писатели, которые отвечают за создание руководства пользователей, тренировочные материалы и справочную систему;

7. менеджер по проекту, который планирует процесс и руководит командой разработчиков вплоть до успешного выпуска продукта;

8. сотрудники правового отдела, которые следят, чтобы продукт не противоречил всем действующим законам и постановлениям;

9. производственники, которые должны построить продукт, содержащий данное ПО;

10. сотрудники отдела продаж и маркетинга, выездной службы поддержки и другие, кому придется работать с продуктом и его пользователями.

Так как требования представляют собой основу для действий и разработчиков и менеджеров проекта, все заинтересованные в проекте лица должны быть вовлечены в создание этого документа.

Требование к ПО состоит из трех уровней – бизнес – требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования.

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

Рис. 1.1. Взаимосвязи нескольких типов информации для требований

Бизнес-требования содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга или специалист по системам машинного зрения – «ясновидец».

В этом документе объясняется, почему организации нужна такая система, т.е. описаны цели, которые организация намерена достичь с ее помощью. Бизнес-требования описывают в виде документа об образе и границах проекта, который иногда называют уставом проекта или документом рыночных требований. Определение границ проекта представляет собой первый этап управления общими проблемами расползания границ.

Требования пользователей описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие - отклик». Таким образом в этом документе указано, что клиенты смогут сделать с помощью системы. Пример варианта использования – «Сделать заказ» для заказа билетов на самолет, аренды автомобиля, заказа гостиницы через Интернет.

Функциональные требования определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда их называют требованиями поведения, они содержат положения с традиционным «должен» или «должна». Например, «Система должна по электронной почте отправлять пользователю подтверждение о заказе». Таким образом, функциональные требования описывают, что разработчику необходимо сделать.

Термином системные требования обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы, т.е. система.

Бизнес-правила включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные варианты использования, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности.

Функциональные требования документируются в спецификации требований к ПО, где описывается так полно, как это необходимо, ожидаемое поведение системы. К спецификации следует как к документу, хотя это может быть база данных или крупноформатная таблица с требованиями, хранилище данных в коммерческом инструменте управления требованиями или даже, может быть, куча карточек для небольшого проекта. Спецификация требований к ПО используется:

- при разработке и тестировании ПО,

- при определении гарантии качества продукта,

- для управления проектом и связанных с проектом функций.

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

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

Чтобы лучше воспринять некоторые из различных видов требований, рассмотрим простую программу подготовки текстов. Бизнес-требование может выглядеть следующим образом: «Продукт позволит пользователю исправлять орфографические ошибки в тексте эффективно». На коробке CD-ROM указано, что проверка грамматики включена как характеристика, удовлетворяющая бизнес-требованиям. Соответствующие требования пользователей могут содержать задачи или варианты использования вроде такой: «Найдите орфографическую ошибку» или «Добавьте слово в общий словарь». Проверка грамматики имеет множество индивидуальных функциональных требований, которые связаны с такими операциями, как поиск и выделение слова с ошибкой, отображение диалогового окна с фрагментом текста, где это слово находится, и замена слова с ошибкой корректным вариантом по всему тексту. Атрибут качества легкость и простота использования как раз и определяет его значение посредством слова «эффективно» в бизнес-требованиях.

Менеджеры и сотрудники отдела маркетинга определяют бизнес-требования для ПО, которые помогут их компании работать эффективнее (для информационных систем) или успешно конкурировать на рынке (для коммерческих продуктов). Каждое требование пользователя должно быть сопоставлено бизнес-требованию. На основе требований пользователя аналитики определяют функции, которые позволят пользователям выполнять их задачи. Разработчикам необходимы функциональные и нефункциональные требования, чтобы создавать решения с желаемой функциональностью, определенным качеством и требуемыми рабочими характеристиками, не выходя за рамки налагаемых ограничений.

Хотя в модели на рис. 1.1 показан поток требований в направлении сверху вниз, следует ожидать и циклов, и итераций между бизнес-требованиями, требованиями пользователей и функциональными требованиями. Кто бы когда бы ни предложил новые характеристики, варианты использования или функциональные требования, аналитик должен спросить: «Они попадают в указанные границы?» Если ответ «да», то они соответствуют спецификации. На «нет», как известно, и суда нет. А вот если ответ «нет, но они должны там быть», то заказчик или тот, кто финансирует проект, должен решить, готов ли он раздвинуть границы проекта, чтобы принять новое требование.

Спецификация требований не содержит деталей дизайна или реализации (кроме известных ограничений), данных о планировании проекта или сведений о тестировании. Эти элементы следует удалить из требований, чтобы из этого документа было абсолютно ясно, что необходимо построить команде разработчиков. Дело в том, что для проекта в целом, как правило, создаются требования других типов, такие как среда разработки, ограничения бюджета, руководство пользователя, требования к выпуску продукта и продвижения его в поддерживаемую среду.

Понятие «требование к ПО» требует уточнения, для чего полезным является разделение этого понятия на собственно разработку требований к ПО и на управление требованиями. Это показано на рис. 1.2.

Разработку требований, можно подразделить на подэтапы извлечение, анализ, документирование, утверждение. В эти подэтапы входят все действия, включающие сбор, оценку и документирование требований для ПО.

К этим действиям можно отнести следующие действия:

- идентификация классов пользователей для данного продукта, выявление потребностей тех, кто представляет каждый класс пользователей;

- определение задач и целей пользователей, а также бизнес-целей, с которыми эти задачи связаны;

- анализ информации, полученной от пользователей, чтобы отделить задачи от функциональных и нефункциональных требований, бизнес-правил, предполагаемых решений и поступающих извне данных, распределение высокоуровневых требований по компонентам ПО, определенным в системной архитектуре;

- установление относительной важности атрибутов качества, т.е. установление приоритетов реализации;

- документирование собранной информации и построение моделей;

- просмотр спецификации требований, который позволяет удостовериться в том, что запросы пользователей всеми понимаются одинаково, и устранение возникших проблем до передачи документов разработчикам.

Постепенность процесса – ключ к успеху разработки требований. Поэтому необходимо планировать цикличность исследования требований, детализировать высокоуровневые требования и уточнять их корректность у пользователей.

Этап управления требованиями определяется как выработка и поддержание взаимного согласия с заказчиком по поводу требований к разрабатываемому ПО. Это соглашение воплощается в спецификации в письменной форме и моделях. Одобрение пользователей – только половина дела. Разработчики также должны принять задокументированные требования и высказаться за создание этого продукта. К действиям по управлению требованиями относятся:

- определение основной версии требований, т.е. моментальный срез требований для конкретной версии продукта;

- просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;

- включение одобренных изменений требований в проект установленным способом;

- согласование плана проекта с требованиями;

- обсуждение новых обязательств, основанных на оцененном влиянии изменения требований;

- отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования;

- отслеживание статуса требований и действий по изменению на протяжении всего проекта.

В связи со сказанным можно представить другой способ разделения областей разработки требований и управления ими (см. рис. 1.3).

В заключение отметим, что основное следствие проблемы с требованиями – переделка того, что как вы думаете, уже готово. На это расходуется от 30 до 50% общего бюджета разработки, а ошибки в требованиях стоят от 70 до 85% стоимости переделки. Следовательно, предотвращение ошибок в требованиях и обнаружение их на ранних стадиях сильно уменьшает объем переделки.

Рассмотрим наиболее общие риски возникновения ошибок в разработанных требованиях к ПО.

Недостаточное вовлечение пользователей. Заказчики не понимают, почему так важно тщательно собрать требования и обеспечить их качество. С другой стороны, разработчики не всегда придают значение вовлечению пользователей в процесс, из-за того, что среди них больше фанатов написания кода, а не любителей возиться с клиентами или же потому, что они считают, что все уже знают о потребностях пользователей. В любом случае трудно добраться до людей, которые непосредственно будут иметь дело с продуктом, и выразители мнения пользователей не всегда понимают, что тем нужно в реальности. Недостаточное вовлечение пользователей ведет к обнаружению ошибок в требованиях на поздних стадиях проекта, а значит к задержке завершения проекта.

«Разрастание» требований пользователей. Так как требования тщательно прорабатываются, то их объем со временем увеличивается. Поэтому проект часто выходит за установленные рамки, как по срокам, так и по бюджету. Первоначально принятые планы не всегда основаны на реалистичном понимании размера и сложности требований, ограничение же на модификацию только усиливает проблемы. Эти проблемы частично кроются в частых запросах пользователей на изменения, а частично – в том, каким способом разработчики отвечают на них.

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

По мере того, как продукт модифицируется в процессе разработки, его архитектура может медленно разрушаться. «Заплатки» кода затрудняют понимание и поддержку продукта. Добавление кода может стать причиной нарушения твердых и взаимосвязанных принципов дизайна и разрыва связей. Чтобы минимизировать возможность потери качества продукта в результате проблем такого рода, вначале необходимо протестировать то, как возможные изменения отразятся на архитектуре и дизайне, а уже потом реализовать их в коде.

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

Двусмысленность ведет и к формированию различных ожиданий у заинтересованных лиц. Впоследствии некоторые из них удивляются «Что же это получилось?» Разработчики же впустую тратят время, занимаясь не теми проблемами. Одновременно тестеры готовятся к проверке не тех особенностей поведения системы.

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

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

Пользователи иногда требуют функции или элементы интерфейса, которые выглядят отлично, но не представляют особой ценности для продукта. Все, что будет добавлено, стоит времени и денег, поэтому следует осознать ценность своевременного выпуска продукта. Чтобы уменьшить «золочение», необходимо отслеживать каждый элемент функциональности до его первоисточника, чтобы четко понимать, почему именно он включен в продукт.

Минимальная спецификация. Иногда сотрудников отдела маркетинга или менеджеров охватывает искушение создать урезанный вариант спецификации, как, например, набросок концепций продуктов на салфетке. Они ожидают, что разработчики «нарастят мясо» на основе этих набросков, пока проект развивается. Это пригодно для тесно сплоченной команды, которая занимается небольшой системой, или когда выполняется проект-исследование, или когда требования действительно гибкие.

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

Небрежное планирование. Неопределенные, недетализированные требования порождают слишком оптимистические оценки. Это «выходит боком», когда возникает перерасход средств. При плохо просчитанной смете проект больше всего страдает из-за затрат на частые изменения требований, пропущенных требований, недостаточного взаимодействия с пользователями, недетализированной спецификации требований и плохого анализа. Если высказывается некоторая оценка требования, то необходимо указать для нее либо качественные показатели типа лучший вариант, наиболее вероятный вариант, худший вариант, либо количественные показатели с учетом личного мнения, например, «Я на 90% уверен, что мы сделаем это за три месяца».

Сформулируем некоторые характеристики, которым должны удовлетворять хорошо составленные требования.

Полнота. Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. Другими словами, требование должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать соответствующий фрагмент программы. Если выяснено, что данных определенного рода не хватает, следует в требованиях сделать отметку в виде флага для выделения такого места. Следует восполнить все проблемы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.

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

Осуществимость. Необходима возможность реализовать каждое требование при известных условиях и ограничениях системы и операционной среды. Чтобы не придумывать недостижимые положения, необходимо обеспечить взаимодействие разработчиков с маркетологами и аналитиками требований на период всего извлечения требований. Разработчики реально оценят, что можно выполнить технически, а что нет, или что сделать можно, но при дополнительном финансировании.

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

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

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

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

Недостаточно получить прекрасные отдельные положения. Набор требований, составляющий спецификацию, должен отвечать следующим характеристикам.

Полнота. Никакие требования или необходимые данные не должны быть пропущены.

Согласованность. Согласованные требования не конфликтуют с другими требованиями такого же типа или с высокоуровневыми пользователями, системными или бизнес-требованиями. Несогласованность документов следует устранить до начала процессов разработки. Не всегда удается выяснить, какое именно положение некорректно, пока не выполнено необходимое исследование. Рекомендуется записывать автора каждого требования, чтобы узнать, кто его высказал, если конфликт все-таки будет обнаружен.

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

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

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

Совместная работа возможна только тогда, когда все участники процесса разработки ПО знают, что необходимо им для успеха, и когда они понимают и уважают стремление их соратников к успеху. В связи со сказанным интересным является перечень прав и обязанностей клиентов и разработчиков ПО. Это перечень оформим в виде своеобразных документов, которые назовем «Билль о правах клиента ПО», «Билль об обязанностях клиента ПО».

Билль о правах клиента ПО при формировании требований.

Клиент имеет право:

1. Иметь дело с аналитиком, который разговаривает на языке клиента.

2. Иметь дело с аналитиком, хорошо изучившим бизнес клиента и цели, для которых создается система.

3. Потребовать, чтобы аналитик преобразовал требования, предоставленные устно, в письменную спецификацию требований к программному продукту.

4. Получить от аналитика подробный отчет обо всех рабочих продуктах, созданных в процессе формулирования требований.

5. На уважительное и профессиональное отношение к клиенту со стороны аналитиков и разработчиков.

6. Знать о вариантах и альтернативах требований и их реализации.

7. Описать характеристики, упрощающие работу с продуктом.

8. Изменить требования или разрешить использование имеющихся программных компонент.

9. Получить исчерпывающие сведения о сумме затрат, ожидаемом эффекте и необходимых компромиссах, которые возникают в связи с изменениями в ПО.

10. Потребовать, чтобы система функциональностью и качеством удовлетворяла требованиям заказчика.

Билль об обязанностях клиента ПО при формировании требований.

Клиент обязан:

1. Ознакомить аналитиков и разработчиков с особенностями своего бизнеса.

2. Потратить столько времени, сколько необходимо, на объяснение требований.

3. Точно и конкретно описать требования к системе.

4. Принимать своевременные решения.

5. Уважать определенную разработчиком оценку стоимости и возможность реализации заданных требований.

6. Определить приоритеты требований.

7. Просматривать документы с требованиями и оценивать прототипы.

8. Своевременно сообщать об изменениях требований.

9. Поддерживать принятый в организации-разработчике порядок контроля изменений.

10. Уважительно относиться к методам, с помощью которых аналитики создают требования.

Результатом сотрудничества клиента и разработчика считается соглашение по требованиям к продукту. Однако, реальность такова, что на ранних этапах над проектом известна лишь часть требований, со временем они могут меняться. Тем не менее, необходимо подтвердить полученные результаты своими подписями. Под подписями рекомендуется сделать примерно следующий текст: «Настоящий документ является базовой (основной) версией и наилучшим образом представляет понимание требований к проекту на данный момент. В базовый документ в будущем могут вноситься изменения».

Лекция 12.

Дата добавления: 2014-01-07