Раздел 2
Требования к системе
В этом разделе будет показано, как формировать функциональные требования к ИС, опираясь на модель предметной области. Изложение будет построено на основе понятия сценария использования, которое является базовым в методологии разработки программного обеспечения 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), трудоемкость которых можно оценить по объему альтернативных потоков.
Конец ознакомительного фрагмента.
