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

В этом разделе будет показано, как формировать функциональные требования к ИС, опираясь на модель предметной области. Изложение будет построено на основе понятия сценария использования, которое является базовым в методологии разработки программного обеспечения IBM RUP (IBM Rational Unified Process)6. В свое время это была одна из ведущих методологий, и если процессы разработки в организации ставились на основе RUP, то это обеспечивало прозрачность и управляемость проекта, т. е. позволяло создавать ИС в соответствии с требованиями заказчика на момент сдачи системы.

RUP определяет роли, задачи, артефакты и 9 процессов, применение которых помогает сделать разработку программного обеспечения предсказуемой. IBM RUP – это оформленная в виде web-сайта электронная энциклопедия «правильной» (Framework) разработки, которая описывает основные процессы создания ИС:

1. Моделирование бизнес процессов.

2. Управление требованиями.

3. Анализ и проектирование.

4. Реализация.

5. Тестирование.

6. Развертывание.

7. Управление изменениями и конфигурациями.

8. Управление проектом.

9. Управление средой разработки.

Далее будем рассматривать методы и технику работы с требованиями к ИС на основе соответствующей «дисциплины» IBM RUP.

Было замечено, что в проектах разработки ИС часто возникают очень похожие друг на друга проблемы:

• Формально ИС удовлетворяет требованиям, однако заказчик не доволен: цели пользователей ИС или бизнес-цели не достигнуты.

• Требования запутаны, постоянно дополняются и изменяются.

• Модули не интегрируются при сборке системы.

• Затруднено сопровождение готового продукта.

• Дефекты, особенно в требованиях, обнаруживаются слишком поздно в проекте.

• Низкое качество рабочих материалов, создаваемых в проекте.

• Низкая производительность ИС при реальной нагрузке.

• Действия в рамках команды плохо скоординированы.

Анализ успешного опыта команд, преодолевших подобные проблемы, позволяет выделить практические паттерны – лучшие практики (Best Practices), которые могут быть использованы в любых проектах, связанных с разработкой ПО.

Rational Unified Process основан на шести лучших практиках:

• итеративная разработка;

• управление требованиями;

• использование компонентной архитектуры;

• визуальное моделирование;

• постоянный контроль качества;

• управление изменениями и конфигурациями.

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

• разработка системы ориентирована на удовлетворение бизнес-потребностей заказчика в автоматизации;

• лучшие практики при их совместном применении усиливают положительные эффекты друг от друга;

• вся команда хорошо понимает, что делать, как делать и когда делать.

Две из этих практик – «Управление требованиями» и «Визуальное моделирование» – мы рассматриваем в книге.

Визуальное моделирование позволяет:

• понять структуру создаваемой системы, которая разбивается на части, компоненты, элементы;

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

• наглядно показать взаимосвязи элементов системы друг с другом;

• обеспечить целостность и согласованность проекта с реализацией системы;

• документировать принятые проектные решения, включая вновь возникающие запросы на изменения;

• скрывать или показывать детали элементов в зависимости от назначения модели и потребностей ее будущих «читателей»;

• обеспечить однозначность коммуникаций внутри команды, которые основаны на использовании моделей системы как «ее чертежей».

Одним из средств для построения визуальных моделей является Unified Modeling Language (UML) – «графический язык», обеспечивающий описание статических и динамических аспектов системы. Методология IBM RUP основана на повсеместном использовании визуальной нотации UML.

Модель описания требований «FURPS+»

Выявление требований согласно модели FURPS+ позволяет создать качественный набор документов в проекте. Аббревиатура FURPS образована из характеристик:

• Functionality – функциональность;

• Usability – удобство использования;

• Reliability – надежность;

• Performance – производительность;

• Supportability – удобство сопровождения.

При этом часть формулировок требований относится к ограничениям на проектирование, реализацию и интерфейсы (значок «+»):

• Design – ограничения проектирования;

• Implementation – ограничения на программную реализацию, например, разработка на заданном языке программирования;

• Interface – ограничения на интерфейсы;

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

Требования и их документирование

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

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

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

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

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

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

В приложении 1 приведены шаблоны этих документов с кратким пояснением разделов.

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), трудоемкость которых можно оценить по объему альтернативных потоков.