 |
Последствия прототипирования. Итоги прототипирования. 20 Обзор методов, используемых при проектировании требований
|
|
|
|
Последствия прототипирования
- После внедрения прототипирования изменяется процесс разработки ПО в целом.
- Прототип пронизывает весь процесс разработки.
- Прототип стал элементом, который все видят и который все обсуждают: от пользователя до программиста.
- Он стал своего рода объединяющим, центральным звеном.
- Он вывел коммуникацию как с заказчиком, так и внутри компании на новый уровень.
- Значительно уменьшилась потеря информации по пути от заказчика к программисту, потому что все видят один и тот же прототип.
- Одноразовые прототипы являются макетом интерфейса, который в последствии не станет частью готовой системы и на определённом этапе будет «выброшен». Такие прототипы создаются и изменяются быстро, поскольку не требуют качественной реализации. Зачастую они создаются в специализированных инструментах без программирования.
Эволюционный прототип – это предварительная реализация программы, альфа-версия, которая по мере своего развития становится всё ближе и ближе к готовому продукту и, в конце концов, становится им. Преимуществом эволюционных прототипов считается то, что, во-первых, уже на ранних стадиях заказчик получает работающую систему, во-вторых, не нужно тратить ресурсы на создание прототипа, который потом будет «выброшен».
Итоги прототипирования
Минусы:
- Трата дополнительных усилий на этапе предпроекта, которые заказчик не всегда готов оплачивать
- Время на обучение инструменту прототипирования.
Плюсы:
- Новый уровень коммуникации с заказчиком и внутри компании
- Ошибки, допущенные в начала проекта и обнаруженные в его конце – самые дорогие. Прототипирование позволяет обнаружить допущенные ошибки на ранней стадии и минимизировать появление новых
- Повышение качества за счёт снижения количества ошибок
- Уменьшение сроков и стоимости разработки за счёт разработки «с первого раза» без необходимости доработки – экономия дефицитного времени разработчика
- У пользователей не возникает отторжения, поскольку они уже знакомы с прототипом, и интерфейс системы не становится для них сюрпризом
- Пользователей, поработавших с прототипом, не нужно обучать работе с системой
- Повышение лояльности заказчика.
|
|
|
20 Обзор методов, используемых при проектировании требований
Посмотрим, как выделенные задачи работы с требованиями решаются в рамках ряда широко используемых методов разработки ПО. В качестве таких методов рассмотрим Унифицированный процесс разработки Rational (RUP), метод, лежащий в основе инструмента управления требованиями DOORS, метод работы с требованиями CORE, метод разработки RAISE и методология нечетких систем (Soft System Methodology, SSM). Эти методы выбраны для анализа, поскольку они достаточно сильно отличаются по базовым идеям и используемым в них техникам.
• Унифицированный процесс разработки Rational (RUP) является одним из самых широко используемых полномасштабных процессов разработки ПО. Базовая идея RUP состоит в том, что процесс разработки ПО должен быть приспособлен к эффективной работе в постоянно меняющемся окружении и производить ПО, решающее проблемы пользователей, даже если они менялись в ходе разработки.
• Метод DOORS лежит в основе использования инструмента управления требованиями DOORS— динамической объектно-ориентированной системы управления требованиями (Dynamic Object-Oriented Requirements System). В основе этого метода лежит представление о том, что требования к сложной системе очень сложны, сильно взаимосвязаны, разнородны и в своем исходном виде не могут быть использованы для разработки. Чтобы стать ее частью, они должны быть подвергнуты поэтапному уточнению, проводимому несколько раз, а также формулироваться совместно с правилами их проверки. При этом крайне важно сохранить всю историю проведенных уточнений и построенных тестов, явно зафиксировать все привлекаемые для этого дополнительные свойства и ограничения окружения, чтобы быть в состоянии анализировать влияние отдельных допущений, возможных изменений требований и покрытие требований в ходе разработки и верификации системы. Основной техникой, используемой в DOORS, является представление требований в виде структурированного набора текстовых и графических документов, моделей и других объектов, имеющих расширяемый набор атрибутов и связанных размеченными связями. Б о льшая часть работ с требованиями выполняется с помощью анализа и модификации этих атрибутов и связей.
|
|
|
• Метод работы с требованиями CORE. Это один из первых методов, предназначенных именно для работы с требованиями в рамках разработки сложных систем. Основная его идея — необходимость учета различных точек зрения на систему при работе с требованиями и привлечения специальных техник для их согласования. Сначала все точки зрения разделяются на два больших класса: точка зрения людей, связанных с разработкой, развитием и поддержкой работоспособности системы, и точка зрения все остальных людей, затрагиваемых системой. Это разделение позволяет рассматривать проблемы, которые система решает, отдельно от используемых ею способов их решения. Техники, используемые в рамках CORE, основаны на иерархической декомпозиции интерфейсов и функций системы с одновременным прослеживанием того, как эти функции задействуются в различных сценариях ее работы (системных транзакциях).
• Методология нечетких систем (Soft System Methodology, SSM) является методом анализа нечетких задач, используемым как для работы с требованиями к сложным системам, так и для анализа их функционирования или управления изменениями в рамках такой системы. Основой SSM является представление о наличии нечетких систем — систем, границы, задачи и само существование которых существенно зависят от наблюдателя. Например, большинство социальных систем нечетки — их границы и решаемые ими задачи не определены однозначно и видятся по-разному с разных точек зрения. Такие системы не имеют четких задач (hard problems), которые можно однозначно сформулировать и для которых имеются четкие критерии того, получено их решение или нет. Вместо этого в них возникают проблемные ситуации, которые характеризуются множественностью и неоднозначностью проблем, множественностью возможных выходов и отсутствием ясного представления о возможном решении. Техники, используемые для анализа нечетких систем, основаны на построении субъективной целостной картины ситуации с определением конфликтующих интересов и целей. В дальнейшем это описание ситуации используется для формулировки различных точек зрения и соответствующих им критериев адекватности создаваемых решений.
|
|
|
• Метод разработки RAISE (строгий подход к промышленной программной инженерии, Rigorous Approach to Industrial Software Engineering). Основная идея метода RAISE — необходимость полной формализации требований для возможности их адекватного включения в процесс разработки. Базовыми техниками RAISE являются определение формальных контрактов компонентов разрабатываемого ПО и их пошаговое уточнение при разработке. При этом формальные спецификации требований сначала представляются в наиболее абстрактной форме, а затем постепенно уточняются до такого состояния, когда на их основе можно создать (или автоматически сгенерировать) полностью исполнимый код.
Техники работы с требованиями, используемые в методах RUP, DOORS, CORE, SSM и RAISE
|
|
|
