Методы формирования требований

4.3.2.1. Метод, основанный на множестве опорных точек зрения.

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

Точки зрения можно трактовать следующим образом.

· Как источник информации о системных данных. В этом случае надо построить модель формирования и использования данных.

· Как структура представления. В этом случае точки зрения рассматриваются как часть модели. Например, диаграмма «сущность-связь».

· Как данные, определяющие системный сервис. В этом случае точки зрения определяют внешние связи (данные).

На рис.4.2. процесс определения требований на основе точек зрения.

 

 

 

 

Рис.4.2.Определени требований на основе точек зрения.

 

методами.

 

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

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

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

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

Проверка требований. Прототип позволяет обнаружить ошибки и упущения в ранее принятых требованиях.

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

Прототип системных требований предполагает частичную реализацию программного обеспечения. Особое внимание уделять ТРЕБОВАНИЯМ, которые неясны, т.е. плохо определены, так как потребности пользователя могут быть:

· хорошо известны;

· частично определенны;

· неизвестны.

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

Прототипирование можно использовать при анализе рисков и на начальном этапе разработки планов управления программным проектом.

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

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

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

В табл.4.3. показаны связи риска проекта с применяемой технологией и изменяемостью требований.

Табл.4.3..

РИСК ПРОЕКТА
Технология	Требования
Развивающийся	Отбрасываемый	Развивающиеся	Отбрасываемые
Архитектура проекта соответствует рабочей версии	Определение осуществимости	Качественный анализ формулирования требований	Широкий набор функциональных требований

 

Риск Количество неуверенности в существующей способности удовлетворить требование.

Эффективность применения прототипов при разработке программного обеспечения состоит в следующем.

1 Улучшаются эксплуатационные качества системы.

2 Система больше соответствует потребностям пользователей.

3 Системная архитектура становится более совершенной.

4 Сопровождение системы упрощается и становится более удобным.

5 Сокращаются расходы на разработку системы.

Различают «эволюционный» и «экспериментальный» прототип (рис 4.4).

Рис. 4.4 – Эволюционное и экспериментальное прототипирование

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

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

Существует различие между целями эволюционного и экспериментального прототипирования.

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

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

 

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

Существует три основных метода быстрой разработки прототипов (макетов).

1 Разработка с применением динамических языков высокого уровня.

2 Использование языков программирования баз данных.

3 Сборка приложений с повторным использованием компонентов.

На практике эти методы часто используются совместно при разработке прототипов системы.

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

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

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

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

 

ВЫВОДЫ.

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

2. Создание прототипа не должно быть дорого стоящим мероприятием, лучше тогда сразу создавать реальную систему.

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

4. Ошибки в определении требований – наиболее распространённые.

5. Стоимость устранения таких ошибок – самая высокая.

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

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

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