Содержание курса
Инфраструктура (ландшафт) для организации проектной деятельности
Инжиниринг бизнес-процессов заказчика. 1. Применение UML Activity
Разработка логической структуры данных. 2. Паттерны проектирования применительно к структуре данных.
Моделирование поведения целевой системы. 1. Теория систем Часть 2
Моделирование поведения целевой системы. 2. Поведенческие диаграммы UML
Моделирование поведения целевой системы. 3. Моделирование процессов управления
Разработка требований на создание целевой ИС. 1. Правила формирования требований
Разработка требований на создание целевой ИС. 2. Формирование Спецификаций требований
Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта
Организация процессов проектирования в производстве ИТ-продукта
5. Формирование спецификаций требований на создание целевого продукта
Вследствие кропотливой, многоэтапной работы проектировщиков и всей команды проекта на свет появился некий результирующий продукт - Требования к целевой Информационной системе. На каждом этапе в качестве входящих ресурсов мы использовали результаты предыдущих, наращивая шаг за шагом понимание и представление о том целевом продукте, который мы должны получить, в результате реализации проекта.
Теперь наступил момент кульминации, когда мы можем специфицировать Требования, взяв за основу все те артефакты, которые получили в процессе проектирования.
Для чего это необходимо делать?
Все полученные артефакты складываются в стройную и полную модель прототипа целевого продукта только в реальности проектировщиков. Если же взглянуть на результат проектирования отстраненным взглядом команды, которой предстоит воплощать эту модель в коде, то окажется, что в общей картине не хватает множества разъяснений, стыковок, структурированности, последовательности исполнения и тому подобного.
Опять же часто команда разработчиков не в полном объеме обладает способностью чтения диаграмм в разных нотациях. А потому их содержание должно быть переведено в более понятное представление, по возможности систематизированное в форме, близкой к структуре задач, поэтапное выполнение которых командой и приведет к тому самому целевому продукту.
Итак, подытожим вышесказанное в виде цели данного этапа: На основании собранной информации о целевом продукте подготовить качественные спецификации требований, позволяющие максимально эффективно организовать процесс их реализации и дальнейшей поддержки.
В конечном счете нам необходимо продумать и зафиксировать:
Состав спецификации требований;
Достаточный уровень детализации;
Форму и порядок представления информации в них.
Такой подход позволит нам:
Обеспечить каждого участника проекта именно теми материалами, которые действительно помогут ему максимально эффективно шпаг за шагом выполнить свою работу в проекте.
Избавить членов команды от бесполезной траты время на изучение артефактов, которые не существенны для них, при выполнении работ в проекте
Регламентировать деятельность команды и четко тарифицировать работы с точки зрения ресурсоемкости
Решение указанных проблем, даст возможность команде поставить процесс разработки ПО на поток и построить технологическую линию по производству ИТ-продуктов.
В идеале у каждой команды, использующей определенный набор инструментов и стек технологий, должен быть некий индивидуальный "конвейер" — виртуальный инструмент, переносящий результаты работ с этапа на этап, от участника к участнику, от моделей домена проблем, к моделям домена решений в рамках организованной технологической линии.
При таком подходе вся деятельность команды регламентирована, а работы четко тарифицированы с точки зрения ресурсоемкости. Этот слаженные механизм регулярно, в соответствии с планами и сметами, сможет выдавать ИТ-продукты.
Итак, для того чтобы подобрать максимально удобный состав спецификаций, нам необходимо понимать ожидания - основных заинтересованных лиц.
• Разработчикам важно: насколько выгодно спецификации будут отличаться, с точки зрения быстрого и точного преобразования их в программный код.
• Менеджеру проекта важно - насколько удобно он сможет «нарезать» спецификации на атомарные задачи для остальных членов команды, группировать задачи в вехи (этапы) проекта и согласовывать на каждом этапе с заказчиков прирост функциональности ИТ-продукта.
• Специалистам по качеству важно - насколько удобно им будет формировать по требованиям – сценарии тестирования, карты приемки и т.п.
• Заказчика же волнует, насколько точно он сможет на всех стадиях реализации представлять себе состояние целевого продукта и его функциональности.
Давайте воспользуемся сопоставлением аналогий реального мира и информационных систем. В этом контексте, будем воспринимать функции аналитика, как интерфейс между заказчиком и командой разработчиков. А домен проблем и домен решений, будем считать системами. Одна система реальная, вторая виртуальная - цифровой двойник. Поэтому нам необходимо продумать протокол, в рамках которого эти две системы смогут эффективно взаимодействовать друг с другом. На роль этого протокола как раз идеально и подходят Спецификации требований.
Спецификация требований (SRS — Software Requirements Specification) — это документ, в котором формально и полно описаны требования к разрабатываемой системе или продукту. Он служит основой для планирования, проектирования, разработки, тестирования и сопровождения ПО.
Для того чтобы отбросить все лишние артефакты, востребованные аналитиком на этапе проектирования, но бесполезные, а иногда и вредные для представления их разработчикам, определимся с объектами, которые должны быть задействованы в нашем протоколе (спецификациях). Другими словами, требуется изолировать слой анализа и проектного дизайна, от слоя реализации конечных спецификаций в целевом продукте.
Для этого необходимо ответить на вопрос: чем же оперируют разработчики, создавая конечный продукт? Поскольку мы в рамках нашего курса не можем рассмотреть все многообразие подходов и технологий, остановимся для примера, на варианте разработки ПО на базе некой технологической платформы с использованием СУБД. В этом случае целевую систему можно представить в виде набора компонентов, постоянное слаженное взаимодействие которых и приводит к “эффекту работающей программы”.
Например, это может быть:
Хранилище данных
Подсистема сценарного языка высокого уровня
Система формирования отчетов
Подсистема запуска периодических заданий
Движок Workflow для интерпретации бизнес-процессов
Подсистема генерации пользовательского интерфейса
Подсистема управления правами доступа
И так далее
Таким образом для выбранного варианта спецификаций обязательно должны быть подобраны форматы описания сущностей предметной области, которые будут интерпретированы в цифровое представление перечисленных выше компонент платформы.
При этом формат описания конкретных экземпляров этих сущностей должен быть максимально пригоден для их дальнейшего конфигурирования в платформе. То есть системный аналитик должен перевести плоды своей работы, на рельсы используемых разработчиками технологий, описав конкретные элементы, алгоритмы их поведения и т.д., в терминах и понятиях выбранной платформы. Степень глубины трансляции может варьировать, в зависимости от компетенции проектировщика и команды разработчиков.
Теперь, когда мы определились с составом элементов спецификаций, давайте определимся со структурой и выясним возможный порядок их представления в документе. Поскольку разные этапы исполнения зависят друг от друга или от результата их деятельности, установим последовательность, в которой удобнее и рациональнее всего реализовывать их в проекте.
На мой взгляд удобнее всего начать с реализации хранилища, поскольку оно не сильно зависит от остальных элементов, а вот от него зависят многие.
Для реализации хранилищ разработчикам, например, может понадобиться информация о:
типе бизнес-объекта, чтобы платформа смога разложить его на таблицы в хранилище;
типах атрибутов, для генерации дополнительных свойств полей в таблицах;
связях бизнес-объектов для генерации вторичных ключей;
фильтруемых полях, для генерации индексов;
возможных состояниях и действиях перехода, для генерации методов и триггеров, поддерживающих поведение;
и прочее.
Соответственно в начале спецификаций должен присутствовать раздел, посвященный требованиям к организации структуры данных, с удобным форматом описания вышеперечисленных характеристик и атрибутов.
Далее, заложив фундамент информационной системы – хранилище информации, мы можем реализовать представление этой информации на экранных формах пользователя.
В этом сегменте еще большее количество вариаций: меню, списки, карточки просмотра и редактирования для разных состояний и прочее. Следовательно, в структуре спецификаций должен присутствовать раздел с описанием визуальных форм и ссылками на описание хранилища, данные из которых и будут так или иначе представлены на формах.
Получив отображение данных на экране, появляется возможность реализовать реакцию системы на действия производимые пользователем, по заполнению атрибутов, выбору меню, нажатию кнопок в виде выполнения процедур и функций. Поэтому в разделе с описанием визуальных форм могут быть представлены варианты разных моделей формы, например, соответствующих определенным состояниям бизнес-объекта на каждом этапе Жизненного цикла. Могут быть описаны алгоритмы и процедуры, применимые к реагированию на события, связанные с интерфейсом пользователя. Но в таком случае такая стилистика должна поддерживаться для всего состава спецификаций, согласно правилу R39 - Руководство по стилю.
Если в платформе используется движок бизнес-процессов, то в спецификациях явно должен быть раздел с описанием процессов, возможно с использованием диаграммами BPMN или других нотаций.
Реализовав же функции и процедуры можно подключать их к подсистеме периодического вызова по расписанию, если в этом есть необходимость.
Когда построена система хранения данных и организовано взаимодействие пользователя с системой, можно формировать различные представления информации в виде отчетов.
Реализовав большую часть элементов системы, можно организовать ограничение доступа к ним, в зависимости от ролей пользователей.
Таким образом команда проектирования и команда разработки договаривается о составе, порядке представления и уровне детализации спецификаций требований.
Для каждого типа проекта (технологии, профессионализм команды, бюджет и прочее) могут быть применены разные шаблоны для сборки требований в спецификации.
С критически важными разделами требований разобрались. Теперь рассмотрим, что же еще необходимо включить в состав.
По ряду причин проектировщики не всегда имеют возможность передать спецификации требований команде разработки очно, объяснив как там все устроено. Поэтому хорошим тоном будет включение в начало документа, раздела с кратким обзором его структуры и представления информации, а также разъяснением, как правильно и эффективно ее использовать.
Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа как обязательных, желательно включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 он называется «назначение и цели создания (развития) системы».
Основная проблема масштабных проектов – необходимость использования большого количества компонентов и связей между ними, к тому же зачастую реализуемых разными командами. Этот факт может значительно затруднять единое представление в воображении членов команд всей картины продукта целиком. Чтобы нивелировать эту проблему, в начало документа можно добавить раздел, описывающий общую компонентную архитектуру целевого продукта. Этот раздел помогает представить на одном (или нескольких) изображениях все основные узловые элементы целевого продукта, а также ознакомиться с описанием способов и режимов взаимодействия их между собой.
Такое представление особенно полезно, когда в проекте участвует несколько команд. Они могут четко определить точки (интерфейсы) соприкосновения компонентов системы, а также своего (команд) взаимодействия. Понимание общей модели позволит на ранних стадиях избежать “провисания” ответственности исполнителей на смежных участках работ.
Если в отдельном документе рассматривается не вся система, а только ее часть, то эту часть можно выделить на диаграмме. Таким образом, в различных документах может повторяться одна и та же диаграмма компонентной архитектуры, но с выделенными разными частями (компонентами).
Когда мы познакомили аудиторию с общими потребностями заказчика и визуализировали архитектуру разрабатываемого продукта, читатель уже имеет представление о его основных функциях и структуре построения системы в целом. Теперь можно перейти к более детальному знакомству с основными сценариями ее использования. В ГОСТ-34.602-89 подобный раздел называется «требования к функциям (задачам), выполняемым системой».
Часто, при оформлении подобных разделов, аналитики используют диаграммы: Вариантов использования (UseCase) или описания Бизнес-процессов (BPMN), или алгоритмов выполнения (Activity), или функциональных моделей в нотации IDEF0 и т.п. Все эти виды диаграмм незаменимы на этапе проектирования, определения рамок проекта и т.п. Но из моего опыта, слишком далеки они от большинства членов команды.
С точки зрения разработчиков, коим предназначен данный документ, гораздо комфортнее работать именно со сценариями использования спроектированной системы, но представленными в виде структурированного текстового описания.
Например, это может быть: агрегированный паспорт бизнес-процесса с основными характеристиками: кто, когда, кому, зачем и представленные в виде иерархии текстовые описания всех составляющих его частей, снабженного ссылками для быстрого перехода на упоминаемые подпроцессы.
Далее, когда разработчики будут реализовывать статические элементы системы, они смогут проецировать их на сценарии и понимать, как же они будут вести себя при использовании системы в динамике. Поэтому желательно использовать в спецификациях ссылки на этот раздел, например, из требований к пользовательскому интерфейсу или к структуре хранилищ.
Важность этого раздела для специалистов по качеству трудно переоценить.
Теперь, когда все ознакомительные разделы подготовлены, можно переходить к формированию основного блока, ключевой части документа – спецификациям функциональных требований, которые мы отобрали, как обязательные и которые послужат отправной точкой для формирования заданий разработчикам.
А для этого спецификации должны быть сгруппированы и хорошо структурированы в виде блоков информации, в соответствии с правилом R42 - Структурированные наборы. Блок самого нижнего уровня, должен представлять из себя атомарное требование, готовое для передачи его разработчику в виде задачи (соответствие свойству C5 – Простота). Поэтому, каждая Спецификация должна содержать информацию, достаточную для того, чтобы разработчик смог однозначно и полно реализовать требование, не обращаясь за разъяснениями и уточнениями к автору (соответствие свойству C4 – Полнота). Такой подход позволит менеджеру проекта пробежавшись по спецификациям, не особо напрягаясь, сформировать из них набор «заготовок» для составления подробного плана-графика проекта. Ну об этом чуть позже.
Как мы договорились в процессе определения структуры и порядка следования спецификаций, этап реализации разработчиками требований должен начинаться с формирования хранилища данных.
Поэтому, в своем варианте спецификаций, первый раздел основного блока я посвящаю этой теме. В начале раздела, для более полного понимания доменной модели, желательно привести общую структуру данных. Это можно сделать при помощи диаграммы классов, она довольно популярна и известна большинству ИТ специалистов. Изображение позволит разработчикам созерцать всю структуру данных модуля в целом. Следом необходимо детализировать спецификации для каждой отдельной Сущности (таблицы), которая используется в модуле, перечислив атрибуты, с указанием: типа данных, заголовка, ограничений, имени в БД, ссылок на другие атрибуты и т.п.
Таким образом разработчикам, получившим подобные требования, остается только транслировать их в код по генерации объектов Базы. Для реализации подобных операций можно привлечь специалистов с невысокой квалификацией и сэкономить бюджет проекта.
Похожий раздел есть в ГОСТ-34.602-89 и называется он «Описание организации информационной базы».
После определения структуры хранилища, которое необходимо реализовать в данном модуле или подсистеме, согласно утвержденной нами структуре, можно приступать к описанию визуальных форм. Помимо макетов в требованиях удобно описать характеристики всех составляющих их элементов. А для этого также удобно использовать табличные представления, в которых указываются, помимо виджетов, позволяющих с ними работать - ссылки на описанные ранее элементы хранилища, данных из которых будут отображаться, а также ограничения и прочие параметры.
А для того, чтобы разработчики полнее представляли, что-же они разрабатывают и как это все будет взаимодействовать на экране, в описании формы следует упомянуть о сценариях, в которых данная форма используется, указав на них ссылку.
Для сложных атрибутов в таблице сразу указываем ссылки на сущность, с которой он связан, а также ограничения для выборки данных, поля для представления на форме, правила переходов по ссылкам и т.д.
При таком подробном и однозначном описании, разработчики могут легко реализовать требования к интерфейсу пользователя в установленные сроки, с прогнозируемым качеством. Глубокая детализация также позволяет привлечь к работам менее квалифицированный персонал и помогает менеджеру проекта эффективно распределить задачи в команде, повышая рентабельность проекта в целом.
После того как специфицированы визуальные формы, можно приступать к программированию их поведения. Поэтому в следующем разделе я обычно представляю все процедуры, которые могут быть выполнены автоматически при обработке событий формы или инициированы пользователем при работе с элементами интерфейса (кнопки, меню и т.п.).
Замечу еще раз, что каждой Спецификации присвоен свой уникальный идентификатор. Эти идентификаторы могут быть применены в качестве ссылок, как в самих требованиях, так и в других артефактах проекта, в том числе на диаграммах.
Если в модуле используются сложные функции, предполагающие описание объемных алгоритмов, определение входящих и выходящих параметров, разработку дополнительной структуры хранения данных и т.д., то я включаю в документ отдельный раздел с требованиями к вспомогательным функциям. На него так же могут ссылаться спецификации, описывающие действия для форм, рассмотренные выше. Например, вспомогательную функцию удобно использовать, когда одна и та же базовая функция вызывается при событиях разных форм.
Похожий раздел есть в ГОСТ-34.602-89 и называется он «Описание алгоритма».
Дальше в документе опционально могут следовать разделы об: Отчетах, Периодических заданиях, Расширенном поиске и т.п. Эти пункты желательно заполнять с таким же уровнем детализации, как показано выше в примерах, указывая ссылки на используемые сущности, процедуры и т.п.
Еще один немаловажный раздел, который должен быть упомянут в документе для подобного рода систем, посвящен правам доступа. В нем идентифицируются Роли, приводится их описание, а дальше указываются права доступа этих ролей к объектам данных и элементам интерфейса пользователя, описанным в спецификациях.
Следующим шагом, для удобства восприятия можно составить матрицы, в ячейках которых будут зафиксированы разрешенные действия для ролей, перечисленных в качестве столбцов, к имеющимся: процедурам, таблицам БД, элементам интерфейса пользователя и т.п., указанным в виде строк. А разрешительные действия можно обозначать, например, в виде первых букв английских слов (C- Create, R-Read, W-Write и т.д.).
Похожий подраздел есть, например, в ГОСТ-34.602-89 и называется он «требования к защите информации от несанкционированного доступа».
Планируя работы по таким детальным спецификациям, еще на ранних стадиях, можно с высокой точностью определить ресурсы и сроки, необходимые для их реализации. Время, которое необходимо затратить на создание таблицы, формы, функции, отчета и т.д. можно просчитать на примере одного проекта и в дальнейшем использовать эти данные как эталонные. А в наших спецификациях, как раз и перечислены все таблицы, формы, процедуры и т.д. и сосчитать их количество не составляет труда.
Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов.
Это очень удобный инструмент для предварительного расчета стоимости кодирования в проекте, а также: тестирования, разработки инструкций и прочих процессов подготовки к передаче заказчику. Такую таблицу можно начать строить еще на этапе формирования спецификаций, в этом случае при их доработке и уточнении, можно наблюдать за изменением требуемых ресурсов и принимать решение о выборе приоритетных работ или целесообразности их реализации вообще.
Взглянем теперь на содержание наших спецификаций. Можно заметить, что они идеально подходят в качестве заголовков задач, выставляемых разработчикам.
Поскольку мы постарались каждую спецификацию нижнего уровня сделать максимально схожей с атомарной задачей для разработчика, то руководителю проекта остается лишь выбрать из требований - спецификации и перенести их в инструмент по формированию плана-графика проекта. Причем пункты спецификации следуют в том порядке, в каком они должны выполняться (мы и об этом позаботились). В добавок, разделы верхнего уровня ложатся в план-график проекта как группа задач, а нижнего непосредственно как задачи. Если заголовок спецификации слишком объемный для заголовка задачи, его можно преобразовывать, но идентификаторы спецификаций всегда остаются, это ось проекта. Ну а дальше, дело техники: планирование рисков, распределение ресурсов и т.д.
Как можно заметить, на основании сценариев из наших спецификаций, также удобно готовить инструкции пользователей и это еще один пунктик, позволяющий сэкономить средства в проекте.
Естественно, этот подход не отменяет и не замещает управление требованиями. Они будут меняться, будут смещается приоритеты, да много что еще может происходить и поэтому желательно использовать трассируемость требований: от самых потребностей пользователей, к высокоуровневым требованиям, дальше к спецификациям и до плана графика проекта. Поэтому мы на каждом шаге использовали идентификацию объектов и выстраивали цепочки из ссылок на связанные артефакты в требованиях.
В следующей части мы разберем, проблемы, связанные с необходимостью изменять требования, а также способы и механизмы их преодоления.