Разработка спецификации
Цель этой стадии — разработка требований к ПО. Она является основой для разработки и проведения приемо-сдаточных испытаний. Главным моментом при составлении Спецификации является достижение взаимопонимания между разработчиком и заказчиком. Все требования к ПО должны одинаково пониматься как Разработчиком, так и Заказчиком. Именно на этой стадии жизненного цикла начинается визуальное моделирование и создаются первые диаграммы на UML. С другой стороны, процесс определения требований к ПО не сводится только к моделированию. От того, насколько полно и детально будут сформулированы требования, во многом зависит успех проекта в целом.
Разработка спецификации включает два основных процесса — обследование организации и анализ и моделирование требований.
Обследование организации (бизнес-анализ)
Цели бизнес-анализа заключаются в следующем:
- понять структуру и динамику работы организации;
- определить проблемы, возникающие в работе организации, и возможности их решения, направленного на повышение эффективности работы организации;
- гарантировать, что заказчики, конечные пользователи и разработчики будут иметь одинаковое понимание деятельности организации;
- вывести требования к программным системам, автоматизирующим работу организации.
Основным результатом бизнес-анализа является бизнес-модель, которая представляется на языке UML. Она включает:
- Структуру организации — статическое описание подразделений организации и отношений подчиненности в виде диаграмм пакетов и/или классов.
- Модель видов деятельности, описывающую бизнес-актеров и виды деятельности организации. К числу бизнес-актеров относятся: партнеры, поставщики, внешние информационные системы и т. д. Виды деятельности представляют собой бизнес-процессы. Модель видов деятельности представляется с помощью use case диаграмм UML и уточняющих их технологических сценариев в виде диаграмм последовательностей и/или деятельностей.
- Объектную модель включающую бизнес-актеров, исполнителей и бизнес-сущности, а также описание их взаимодействий при реализации видов деятельности.
- Модель предметной области, которая является подмножеством объектной модели. Она описывает основные бизнес-сущности и связи между ними. Эта модель представляется в виде диаграмм классов.
При построении бизнес-модели используют нормативные документы организации (устав, штатное расписание и др.), а также информацию, предоставляемую заинтересованными лицами, для чего проводятся интервью и совещания, заполняются анкеты и опросные листы. Организация описывается как с внешней точки зрения — какие результаты предоставляются ее клиентам,- так и с внутренней — исполнители и их связи с деятельностью организации.
Кроме бизнес-модели создаются глоссарий — документ, содержащий определения основных понятий, используемых в данном бизнесе, и бизнес-правила — текстовый документ, определяющий условия и ограничения, которым должен удовлетворять бизнес.
Созданная в итоге бизнес-модель, является основой для последующего моделирования ПО. Такое преобразование может быть формализовано. Необходимо выделить те виды деятельности, которые подлежат автоматизации, и объявить их вариантами использования ПО, а также преобразовать исполнителей в актеров, поскольку они являются внутренними сущностями организации, но внешними по отношению к ПО. Модель предметной области включается как составная часть в логическую модель ПО, а технологические сценарии являются источником для определения потоков событий в варианты использования.
Анализ и моделирование требований
Требование — это условие или характеристика, которой должно удовлетворять разрабатываемое ПО. Функциональные требования определяют действия, которые должно выполнять ПО, без учета физических ограничений. Нефункциональные требования не описывают поведение ПО, но описывают его атрибуты или атрибуты окружения.
Целями процесса анализа и моделирования требований являются:
- достижение соглашения между Разработчиком и Заказчиком о том, что должно делать ПО;
- ограничение функциональности ПО;
- создание базиса для планирования разработки проекта;
- определение пользовательского интерфейса;
- составление Спецификации требований (Технического задания).
Для достижения поставленных целей технология предусматривает создание следующих документов:
- Модель требований;
- Спецификация;
- Глоссарий.
Эти документы описывают, что должно делать ПО (но не как оно это делает!). Источниками информации являются эксперты заказчика и потенциальные конечные пользователи.
Модель требований служит для достижения соглашения между заказчиком, пользователями и разработчиками. Она позволяет заказчикам и пользователям убедиться в том, что ПО будет делать то, что они ожидают, а разработчикам создать то, что требуется. Модель требований включает актеров и варианты использования (use cases). Каждый вариант использования детально описывается, последовательно показывается, как ПО взаимодействует с актерами и что оно делает в каждом варианте использования. Эта модель является основой всего жизненного цикла ПО, она используется при дизайне, реализации и тестировании.
Спецификация описывает все требования к ПО (функциональные и нефункциональные). Она представляет собой текстовый документ, который определяет набор требований к конечному продукту (но не к процессу его разработки) и не содержит деталей реализации. Спецификация составляется как результат совместной работы аналитиков из Разработчика и экспертов Заказчика и является базисом для достижения соглашения между заказчиком и исполнителем.
Спецификация должна описывать:
- Функциональность. Что должно выполнять ПО? Все требования, перечисляемые в этом разделе, должны быть точно сформулированы и одинаково пониматься заказчиком и исполнителем.
- Внешние интерфейсы. Как ПО взаимодействует с пользователями, оборудованием и другими системами?
- Атрибуты ввода и вывода. Определяют вводимые и выводимые данные.
- Ограничения на функциональность.
- Производительность. Скорость, надежность, время ответа, время восстановления и т. д.
- Прочие нефункциональные требования.
Глоссарий определяет терминологию, общую для всех моделей и текстовых описаний ПО. Он расширяет глоссарий, созданный при обследовании организации.
Этот процесс включает три основных вида деятельности — Моделирование требований, Архитектурный анализ, и Функциональный реинжиниринг
Построение модели требований
При использовании ОО подхода создается модель требований, которая служит для представления функциональных требований в удобном для понимания человеком графическом виде. Она включает актеров и варианты использования (ВИ), описываемые на UML в виде use case диаграмм.
Актером будем называть внешнюю по отношению к ПО сущность, которая может взаимодействовать с ним. Актерами могут быть как люди, так и внешние системы или устройства. Актер — это не конкретный человек или устройство, а роль (должностная обязанность), в которой он выступает по отношению к ПО.
При взаимодействии актера с ПО последнее выполняет ряд работ, которые образуют вариант использования ПО. Каждый актер может использовать ПО по-разному, то есть инициировать выполнение разных ВИ. Таким образом, каждый ВИ по существу есть некоторое функциональное требование к ПО (которое может быть иерархически разбито на несколько более мелких). Каждый ВИ детально описывается, последовательно показывается, как ПО взаимодействует с актерами и что оно делает в каждом ВИ. В дальнейшем при разработке ПО модель требований развивается в модель анализа и дизайна и является основой для тестирования.
Для детального описания каждого ВИ в модель включаются сценарии взаимодействий в виде диаграмм взаимодействий и деятельностей UML. Каждый такой сценарий обычно показывает актеров, а также объекты, отвечающие за интерфейс пользователя с ПО, объекты, хранящие данные. Детальное описание ВИ в текстовом виде включается в Спецификацию.
Правила и рекомендации по определению актеров и ВИ, построению модели требований и составлению Спецификации изложены в Методике моделирования требований, разработанной в CorePartners International.
Архитектурный анализ
При составлении Спецификации архитектурный анализ выполняется с целью определения нефункциональных требований к ПО. При этом определяются различные архитектурные представления, которые позволяют сформулировать и внести в Спецификацию некоторые нефункциональные требования. Кроме того, определяются параметры качества, которым должно удовлетворять ПО (производительность, масштабируемость, настраиваемость и др.). Анализ архитектурных представлений позволяет определить допустимые значения некоторых параметров качества и отклонить заведомо нереализуемые нефункциональные требования.
Функциональный реинжиниринг
Эта деятельность выполняется только при разработке ПО, наследующего функциональность существующего и используемого Заказчиком (наследуемого) ПО. Поскольку при этом функциональность наследуемого ПО должна сохраняться (полностью или частично), значительная часть требований определяется путем реинжиниринга наследуемого ПО. Реинжиниринг позволяет восстановить модель наследуемого ПО (полностью или частично), а также модель данных. При проведении реинжиниринга используются возможности автоматизации, предоставляемые инструментальными средствами визуального моделирования.
Описание функциональности наследуемого ПО выполняется в виде use case диаграмм и детализирующих их диаграмм последовательностей и деятельностей. Эти диаграммы могут быть включены в модель требований напрямую или в преобразованном виде с учетом согласования с уже имеющейся частью этой модели.