автордың кітабынан сөз тіркестері  Системный Анализ. Предметная область. Модели на UML

Михаил Кумсков

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

При идентификации сценариев был использован паттерн CRUD. Если внутри рассматриваемой системы ведется картотека, то операции по работе с этой картотекой — создание записи — Create, чтение записи — Read, изменение и сохранение — Update и удаление записи — Delete) — представляют собой один сценарий использования (а не четыре сценария).

Выявление сценариев использования — задаем вопросы:

• Какова цель каждого эктора при взаимодействии с системой?

• Для чего эктор будет использовать систему?

• Будет ли эктор создавать, хранить, изменять, удалять или читать данные из системы?

• Будет ли эктор информировать систему о внешних событиях или изменениях?

• Необходимо ли эктора информировать о каких-либо изменениях в системе?

Выявление экторов — задаем вопросы:

• Кто использует систему?

• Кто получает информацию от системы?

• Кто вносит информацию в систему?

• В какой части организации система будет использоваться?

• Кто поддерживает работоспособность системы?

• Какие другие системы используют эту систему?

Определение границ системы — задаем вопросы:

• Какие внешние интерфейсы должны быть реализованы в разрабатываемой системе?

• Каким образом сценарии использования могут помощью понять границы проекта?

• Что должно входить в систему?

• Что не должно входить в систему?

Сценарии использования и их идентификация
Выявление сценариев использования будем проводить по шагам:

• Определяем «границы системы». Все то, что будет внутри системы, пока не рассматриваем, а все то, что будет вне системы, выявляем на втором шаге. Фактически здесь мы устанавливаем «систему координат» для всех последующих рассмотрений — систему как «черный ящик».

• Определяем, «Кто» или «Что» будет обмениваться информаций. С ней по постановке задачи будут взаимодействовать пользователи («Кто»). Система будет обмениваться информацией с другими уже существующими системами («Что»). Наличие «actors» в модели представляет собой требования к интерфейсам системы.

• Цикл по найденным пользователям системы. Для каждого эктора-пользователя выявляем те услуги, которые пользователь ожидает от взаимодействия с системой. Эта услуга и будет «сценарием использования» системы, рассматриваемым как «черный ящик». Каждая такая услуга имеет текстовое описание взаимодействия эктора-пользователя и системы.

Набор всех текстовых описаний, созданных для каждого сценария, называется «моделью сценариев использования», к которой добавляется UML Use Case диаграмма.

объем работ (Scope), о котором следует договориться заинтересованным лицам с командой проекта, формулируется в документе Vision как список бизнес-требований к системе (Features).

Последовательность обработки требований
1. Выявить заинтересованных лиц (stakeholders, список ведется в Vision).

2. Собрать их пожелания (набор документов — Stakeholder Requests).

3. Выделить (путем символьной разметки) в пожеланиях ключевые потребности (needs) и классифицировать их:

• симптомы бизнес-проблем («issues»);

• действующие лица (пользователи, «needs-actors»);

• варианты использования («need-use cases»);

• бизнес-правила и бизнес-процессы («needs-business rules», «needs-business processes»);

• ограничения (needs-constraints).

4. Основные термины проекта описать в Глоссарии (Glossary), используя модель предметной области.

5. Проанализировать симптомы и сформулировать основную бизнес-проблему, на решение которой будет направлена разрабатываемая ИС (секция Problem Statement формулируется в Vision).

6. Отобрать потребности (Needs), соответствующие предложенному направлению решению проблемы (Problem Statement используется как фильтр).

7. Для отобранных потребностей (на основе Глоссария) сформировать перечень бизнес-требований к разрабатываемой системе (Features формулируется в Vision). Построить матрицу трассировки Needs и Features.

8. На основе модели предметной области выявить сценарии использования. Построить UseCases диаграмму на UML.

9. Описать эскизы (Outline) сценариев использования (UseCases), трудоемкость которых можно оценить по объему альтернативных потоков.

10. Провести трассировку UseCases и Features для оценки трудоемкости бизнес-требований к ИС.

11. Описать другие требования к системе (FURPS+), собрав их в Спецификации требований (Requirement Specifications).

12. Выполнить первоначальную оценку сложности реализации бизнес-требований (efforts).

13. Разработать план реализации сценариев использования по итерациям.

14. На каждой итерации эскизы сценариев вариантов использования дополнить до полной спецификации сценария использования.

15. На протяжении всего процесса документирования требований пополнять Глоссарий по мере необходимости.

Основными видами артефактов, содержащих описания требований к системе, согласно IBM RUP являются:

• запросы заинтересованных лиц (ЗЛ — Stakeholder Requests);

• глоссарий (Glossary).

• видение (Vision);

• модель сценариев использования (Use Case Model, состоит из Use Case Specification);

• дополнительные спецификации (Supplementary Specification).

Модель сценариев использования (Use-case Model) представляет собой набор текстовых описаний для каждого выявленного сценария. Шаги сценария со стороны системы представляют собой функциональные требования к ИС. Сценарий использования (Use-case) — это ключевое понятие RUP, которое является единицей организации работ в проекте (т. е. это единица планирования, проектирования, отладки и тестирования ИС). Модель сценариев использования является основой для эффективного планирования работ и управлению проектом, без его использования эффективность работы в проекте существенно снижается.