Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Архитектура и проектирование программных систем

РАЗРАБОТКА ПРЕДВАРИТЕЛЬНОГО ВНЕШНЕГО ПРОЕКТА

Представление и анализ требований

Требования в У-модели Халла

Жизненно важная часть проектирования любых систем - это разработка требований, которые в первую очередь определяют саму предметную область, а затем последовательно соотносят все последующие технические решения с конкретными проблемами из этой предметной области [29]. Требования являются основой для любого проекта. Они определяют те потребности заинтересованных сторон (пользователей, потребителей, поставщиков, разработчиков и самого бизнеса), которые являются для них необходимыми, а также тот функционал, которым система должна впоследствии обладать, чтобы удовлетворить эти потребности.

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

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

Таким образом, требования являются базой для планирования проекта, управления рисками, приемочного тестирования, установления компромиссов (согласований) и управления изменениями.

Анализ требований включает [2]:

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

В SWEBOK [2] отмечается, что традиционный взгляд на анализ требований часто сфокусирован или уменьшен до вопросов концептуального моделирования с использованием соответствующих аналитических методов, одним из которых является SADT - Structured Analysis and Design Technique (методология структурного анализа и техники проектирования), известный по нотациям IDEF0 (функциональное моделирование- стандарт IEEE 1320.1), IDEF1X (информационное моделирование- стандарт IEEE 1320.2, известный также как IDEFObject), часто применяемым для моделирования как бизнес-процессов, так и структур данных, в частности реляционных баз данных.

Fie следует считать, что разработка требований - это единичная фаза, которая выполняется в начале разработки продукта. Очевидно, что требования, разработанные в начале проекта, так или иначе используются на его самом последнем этапе (рис. 5.1). Классическая К-модель [29], описывающая различные стадии проекта, в основном базируется на связи между требованиями и их тестированием.

Пользовательские

требования

определение результата для заинтересованных сторон,

приемка продукта

Приемочные тесты

Системные

требования

определение того что система должна делать. проверка системы

оптимизация затрат/пользы, проверка требований

Требования к подсистемам

Интеграционные

тесты

определение реализации требований, проверка компонентов

Системные тесты

Модульные тесты

Требования для компонентов

Рис. 5.1. Классическая К-модель Халла

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

проектами. Это хорошая идея, по мнению Халла [29], потому что организации-разработчики желают:

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

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

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

  • • принять или отклонить изменение;
  • • согласовать стоимость изменения с заказчиками (поставщиками);
  • • организовать работы по переделке.

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

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Пред   СОДЕРЖАНИЕ   След >
 

Популярные страницы