Ответы на экзамен (987689), страница 12

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 12)

Анализ состоит из двух подфаз:

∙••••••• Определение требований.

∙••••••• Уточнение и структурирование требований.

4.2.1. Определение требований

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

∙••••••• Перечисление возможных требований.

∙••••••• Описание контекста системы.

∙••••••• Определение функциональных требований.

∙••••••• Определение нефункциональных требований.

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

∙••••••• Состояние предложения (предложено, одобрено, включено в план работ).

∙••••••• Сметная стоимость реализации.

∙••••••• Приоритет (критический, важный, вспомогательный).

∙••••••• Уровень риска, связанного с реализацией предложения.

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

Описание контекста системы может быть выполнено двумя способами:

∙••••••• Моделирование предметной области.

∙••••••• Бизнес – моделирование.

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

В более сложных случаях модель предметной области можно описать диаграммой классов (в относительно простых предметных областях 10-50 классов). Напомним, что модель предметной области должна описывать именно контекст (т.е. окружение) разрабатываемой системы, а не ее внутреннюю структуру. Глоссарий и модель предметной области обеспечат единообразное применение терминов всеми участниками разработки. Также они могут в дальнейшем помогать при определении внутренних классов. Эта модель описывает статику предметной области.

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

Бизнес – модель является надмножеством над моделью предметной области и ее составление - более сложный процесс. Целесообразность создания упомянутых моделей решается каждый раз отдельно руководителем проекта.

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

Определение нефункциональных требований заключается в уточнении ограничений на среду реализации, объемно-временные характеристики, требования к надежности, требования к защите данных. Нефункциональные требования могут быть связаны с вариантами использования (например, ограничения на время отклика) или относиться к системе в целом (например, надежность). В таблице 4.1. представлено резюме изложенного.

Таблица 4.1.

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

Действующие лица и варианты использования выделяют для:

∙••••••• отделения системы от окружения;

∙••••••• определения, какие действующие лица взаимодействуют с системой и какие функциональные возможности ожидаются от системы.

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

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

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

Выделенные действующие лица должны быть идентифицированы и снабжены кратким описанием.

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

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

2. Какие существуют пути реализации варианта использования: выбираемые действующим лицом или зависящие от хода выполнения?

3. Как заканчивается выполнение варианта использования? Какие имеются конечные состояния? Как о результате узнает действующее лицо?

4. Какие существуют запрещенные пути выполнения? Как предотвращается их запуск? Должно ли передаваться сообщение о попытке их запуска?

5. Что в процессе выполнения делает действующее лицо и что делает программа?

6. Какие исходные данные (пока на качественном уровне) требуются от действующего лица?

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

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

При разработке прототипов пользовательских интерфейсов для действующих лиц необходимо получить ответы на следующие вопросы:

1. Какие элементы пользовательского интерфейса необходимы ему для выполнения его вариантов использования?

2. Какие действия он может производить?

3. Какую информацию он должен вводить при запуске различных вариантов использования?

4. Каким образом он будет информирован о результатах выполнения (с учетом того, что ход выполнения и результат могут быть различными)?

Заканчивается эта подфаза структурированием модели вариантов использования, в ходе которого:

∙••••••• извлекаются общие и совместно используемые разными действующими лицами описания функциональности;

∙••••••• извлекаются дополнительные и необязательные описания функциональности;

∙••••••• проводят классификацию действующих лиц.

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

Подведем итоги. В результате выполнения работ по определению требований должны быть получены (программа-минимум):

1. Модель вариантов использования (одна или несколько диаграмм).

2. Эскизы интерфейсов пользователей для всех действующих лиц.

3. Описания вариантов использования.

4. Основные нефункциональные требования.

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

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

Таблица 4.2.

Характеристики

Список файлов ответов (шпаргалок)