Недостатки модели:
–Мониторинг рисков требует дополнительных ресурсов, а значит, эта модель может оказаться весьма затратной. Каждая итерация требует отдельной экспертизы, что делает управление проектом сложнее. Именно поэтому спиральная модель плохо подходит для небольших проектов;
–Большое количество промежуточных стадий разработки. Как следствие большой объем документации;
–На самых ранних стадиях дата завершения работы над проектом может быть неизвестна, что также усложняет контроль над процессом разработки
Применение спиральной модели.
Спиральная модель может оказаться полезной, если предстоит работа над проектом со средним или высоким уровнем возможных рисков, заказчик не может предоставить достаточно четкий список требований к конечному продукту или эти требования достаточно сложные, а также в том случае, когда ожидаются значительные изменения в процессе разработки.
Требования.
Требования – это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут быть ограничены процессом разработки системы.
IEEE Standard Glossary of Software Engineering Terminology (1990) определяет требования как:
1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
3. Документированное представление условий или возможностей для пунктов 1 и 2.
Это определение охватывает требования как пользователей (внешнее поведение системы), так и разработчиков (некоторые скрытые параметры). Термин пользователи следует распространить на всех заинтересованных лиц, так как не все, кто заинтересован в проекте – пользователи.
Классификация требований.
Бизнес-требования – это высокоуровневые формулировки целей, задач и потребностей предприятия. Они описывают причины, по которым был инициирован проект, задачи, которые будут достигнуты в ходе проекта, а также метрики, которые будут использоваться для измерения его успешности. Бизнес-требования описывают потребности организации в целом, а не группы или заинтересованных в нем сторон. Они разработаны и определены на основе анализа предприятия.
Требования заинтересованных сторон – это формулирование нужд конкретного заинтересованного лица или класса заинтересованных лиц. Эти требования описывают потребности, которые описывают что заинтересованная сторона имеет и как эта заинтересованная сторона будет взаимодействовать с решением. Требования заинтересованных сторон служит в качестве моста между бизнес-требованиями и другими классами требований к решению. Они разработаны и определены на основе анализа требований.
Требования к решению описывают характеристики к решению, которые соответствуют бизнес-требованиям и требованиям заинтересованных сторон. Они разработаны и определены на основе анализа требований. Их часто делят на подкатегории, особенно в случаях, когда требования описывают программное решение:
Функциональные требования описывают поведение решения и информацию о том, чем оно будет управлять. Эти требования описывают возможности системы, которые доступны к выполнению, в части режимов работы или операций – действия или реакции конкретного ИТ-приложения.
Нефункциональные требования фиксируют условия, которые напрямую не относятся к поведению или функциональности решения, а скорее описывают условия окружающей (внешней) среды, в условиях которой решение должно сохранять эффективность и качества, которыми система должна обладать. Они также известны как требования качества или дополнительные требования. Они могут включать в себя требования, связанные с мощностью (емкостью), скоростью, безопасностью, доступностью, информационной архитектурой и пользовательским интерфейсом.
Переходные требования описывают возможности, которыми решения должно обладать для осуществления перехода из текущего состояния предприятия к желаемому (требуемому) состоянию в будущем. Эти требования статут ненужными, как только этот переход завершится. Они отличаются от других типов требований, потому что они всегда носят временный характер и потому, что они не могут быть разработаны, пока оба решения, существующее и новое, не будут определены. Как правило, они охватывают преобразование данных из существующих систем, пробелы в знаниях и квалификации, которые должны быть решены, а также другие соответствующие изменения, необходимые для достижения желаемого будущего состояния. Их разрабатывают и определяют посредством проведения оценки и валидации (проверки) решения.
Методы сбора требований:
– Мозговой штурм;
– Анализ документов;
–Фокус-группы;
– Анализ интерфейсов;
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
