Модель прецедентов системы состоит из всех акторов ПО и различных прецедентов, посредством которых акторы взаимодействуют с ПО. Она также показывает связи между прецедентами.
Первый шаг моделирования прецедентов состоит в создании системной диаграммы, описывающей границы системы и определяющей акторы. Это позволяет параллельно осуществить этапы анализа проблемы, в которых требуется выявить заинтересованных лиц системы и определить ее границы.
Дальнейший анализ показывает, что для поддержки потребностей пользователей необходимы определенные сценарии системного поведения. Эти сценарии и есть прецеденты, с помощью которых пользователи взаимодействуют с ПО для достижения определенных целей.
Заключение. Прецеденты являются структурированной и разумно формальной нотацией для фиксации очень важного подмножества информации о требованиях: как система взаимодействует с пользователем при предоставлении своих функциональных возможностей.
Каждый выявленный прецедент определяет требуемое поведение системы с точки зрения определенного класса пользователей. Поэтому данный метод очень полезен в выявлении потребностей пользователей и помогает команде разработчиков представить эти потребности в понятной пользователям форме.
Прецеденты можно применять позднее в процессе проектирования и тестирования, они обеспечивают целостное представление и последовательность согласованных действий по выявлению требований, анализу, проектированию и тестированию.
Таким образом, данный метод на раннем этапе создает активы проекта, которые можно повторно использовать. Прецеденты настолько важны, что их применяют, начиная с формирования требований, они являются неотъемлемой составной частью деятельности команды по управлению требованиями.
|
|
Когда прецеденты не являются наилучшим вариантом?. Системы, в которых доминируют нефункциональные требования и ограничения проектирования. *
LABA 6 7
1. Особенности методов.
1 Сценарии. Сценарии особенно полезны для детализации уже сформулированных требований.. Каждый сценарий описывает одно или несколько возможных взаимодействий.
Последовательность действийпри разработке сценариев.
· Описание состояния системы в начале сценария.
· Описание нормального протекания событий.
· Описание исключительных ситуаций и способов их обработки.
· Описание информации и действий, которые можно осуществить во время выполнения сценария.
2 Этнографический метод. Используется для понимания и формирования социальных и организационных аспектов эксплуатации системы. Он помогает обнаружить неявные требования к системе, которые отражают реальные аспекты ее эксплуатации, а не формальные умозрительные процессы.
Этнографический метод позволяет детализировать требования для критических систем. Но этот метод не может охватить все требования предметной области. Поэтому он должен применяться совместно с другими методами.
3 Методы прототипирования
Прототипы требований к ПО – это частичная реализация ПО, созданная с целью помочь разработчикам и пользователям понять требования к системе.
Прототип ПО помогает на двух этапах процесса разработки системных требований.
Постановка требований. Разработчики могут экспериментировать с системными прототипами, что позволяет им проверять, как будет работать система. В результате могут сформироваться новые требования.
|
|
Проверка требований. Прототип позволяет обнаружить ошибки и упущения в ранее принятых требованиях.
Прототипирование облегчает проверку полноты набора требований, потому что моделируются все основные информационные потоки вход-выход. При этом анализируется поведение системы при правильных и неправильных информационных потоках.
Прототип системных требований предполагает частичную реализацию ПО.
Потребности пользователя в конечном результате влияют на выбор технологии, что в свою очередь определяет процесс построения прототипа.
Эффективность применения прототипов при разработке ПО состоит в следующем.
1 Улучшаются эксплуатационные качества системы.
2 Система больше соответствует потребностям пользователей.
3 Системная архитектура становится более совершенной.
4 Сопровождение системы упрощается и становится более удобным.
5 Сокращаются расходы на разработку системы.
Различают «эволюционный» и «экспериментальный» прототип (рис 1.1).
Рисунок 1.1.– Эволюционное и экспериментальное прототипирование
Существует различие между целями эволюционного и экспериментального прототипирования.
1. Целью эволюционного прототипирования является поставка работающей системы конечному пользователю.
Эволюционное прототипирование начинается с построения относительно простой системы, которая реализует наиболее важные требования пользователя.
|
|
Это означает, что необходимо начать создание системы реализующей требования пользователя, которые наиболее понятны и которые имеют наивысший приоритет. По мере выявления новых требований прототип изменяется и дополняется. Требования с более низким приоритетом и нечеткие требования реализуются позже.
Прототипирование – необходимая часть процесса проектирования интерфейса «пользователь-ПК». Из-за динамической природы интерфейса «пользователь-ПК» текстовых описаний и диаграмм недостаточно для формирования требований к нему. Поэтому эволюционное прототипирование – приемлемый способ разработки интерфейса для программных систем.
В итоге прототип становится той системой, которая требуется.
2. Целью экспериментального прототипирования является проверка и формирование системных требований.
Метод экспериментального прототипироваиия предназначен для разработки и уточнения системной спецификации. Сначала создается прототип, реализующий те требования, которые сформулированы нечетко и с которыми необходимо "разобраться". Прототип создается, оценивается и модифицируется. Требования, которые сформулированы четко и понятно, не нуждаются в прототипировании.
Данные оценивания прототипа используются для дальнейшей детализации спецификации. Когда системные требования сформированы, прототип больше не нужен
4.Кроме эволюционного и экспериментального» прототипирования существуют технологии ускоренного прототипирования, которые рассчитаны главным образом на обеспечение быстрой разработки прототипов, а не на такие их системные характеристики, как производительность, удобство эксплуатации или безотказность.
Существует три основных метода быстрой разработки прототипов (макетов).
1. Разработка с применением динамических языков высокого уровня.
2. Использование языков программирования баз данных.
3. Сборка приложений с повторным использованием компонентов.
На практике эти методы часто используются совместно при разработке прототипов системы.
Макет является конкретной исполняемой моделью выбранных аспектов предлагаемой системы. Если требования неясны или подозреваемы в неполноте, полезно разработать макет, основанный на экспериментальных требованиях, чтобы исследовать, какие требования к программному обеспечению действительно существуют. Макеты могут помочь определить требования пользователя по интерфейсу.
Из-за динамической природы пользовательских интерфейсов, текстовых описаний и диаграмм недостаточно для формирования требований к интерфейсу.
Ускоренное прототипирование представляет собой процесс быстрого построения и оценки семейства макетов. Спецификация и разработка выполняются по итерационному процессу. Ускоренное прототипирование е нуждается в поддержке CASE-средствами разработки, иначе макетирование не может быть достаточно быстрым, чтобы применяться.
Проект ускоренного макетирования мог бы состоять из нескольких коротких жизненных циклов. Средства разработки ускоренного макетирования могли быть широко использованы в ранних жизненных циклах, позволяя быструю разработку первых макетов. В поздних жизненных циклах программный продукт уже оптимизируется.
LABA 8
1. Теоретический материал.
Средства автоматизации CASE должны использоваться во всех проектах, т.к. они делают ясные и последовательные модели более легкими по построению и модифицируемости.
На рис. 1.1 показана связь между бизнес-моделью и физической моделью (архитектурой) приложения.
Пользовательская модель соответствует требованиям заказчика (мандатным, функциональным, ограничительным). Эта модель отражает необходимые виды связей (интерфейсные, аппаратные, программные, взаимодействия "человек-компьютер")
Логическая модель должна строиться итеративным путем. Некоторые задачи могут нуждаться в повторении до тех пор, пока описание каждого уровня станет ясным и последовательным.
Логическая модель является:
· упрощенным описанием системы;
· иерархической, с последовательным разложением на составные части;
· сочетаниями символов, образованных согласно некоторому договору;
· построенной путем использования одобренных методов и средств разработки;
· используемой для обоснования программного обеспечения.
Для нисходящей реализации логической модели используются:
· функциональная декомпозиция;
· структурный анализ;
· объектно-ориентированный анализ;
· формальные методы.
В её состав обязательно входит перечень необходимых документов, с указанием определённых стандартов, которым они должны соответствовать.
Технологическая модель содержит описание компонент (возможно ранее использованных), потоков данных, обоснование использованных инструментальных средств.
Физическая модель - это описание реализации программного обеспечения.