Операционно-ориентированное управление требованиями

Операционно-ориентированное управление требованиями к программному обеспечению

Введение

Управление требованиями является одним из основных процессов разработки программного обеспечения, и состоит из ряда стандартных этапов, например, для разработки системы некоторого автоматизации бизнес-процесса, в общем случае присутствуют следующие основные шаги:

-       описание автоматизируемого бизнес-процесса;

-       сбор требований заказчика по автоматизации бизнес-процесса;

-       структурирование требований к системе автоматизации;

-       детализация требований;

-       утверждение требований в виде документа Техническое задание;

-        управление изменениями требованиями на этапах разработки, тестирования и эксплуатации системы.

 

В данной статье будет предложена операционная-ориентированная методология управления требованиями, позволяющая значительно повысить эффективность и качество разработки основного продукта процесса управления требованиями – документа "Техническое задание на разработку программного обеспечения".

Методология апробирована и внедрена в качестве стандарта разработки технических заданий в крупной российской компании.

Вопросы, не решаемые в традиционных подходах управления требованиями

В этом разделе будут затронуты основные проблемы разработки документов "Техническое задание", послужившие основанием для поиска и разработки собственной операционной методологии управления требованиями и, если смотреть дальше, "Операционно-ориентированного программирования" – технологии разработки систем автоматизации бизнес-процессов.

Что и как будет делать система?

На этот по моему опыту вопрос не отвечает ни один документ, рождающийся в известных процессах управления требованиями.

Если управление требованиями проводится в соответствии с практикой разработки комплекта документов ГОСТ 34:

-       документ "Техническое задание" будет носить чисто декларативный и формальный характер, понять конструкцию системы из него нет никакой возможности, максимум, будет краткое описание автоматизируемого процесса и схема архитектуры ПО;

-       документ "Пояснительная записка к техническому проекту" – описание технических решений, архитектуры системы, структуры данных и отдельных алгоритмов.

Даже объединив эти два документа получить целостное представление о системе из моего опыта – невозможно, не говоря о том, чтобы передать её на сопровождение от одной группы разработчиков – другой. 

RUP:

-       документ "Спецификация требований к программному обеспечению" – документ в большей степени, чем ТЗ в ГОСТ ориентирован на требования, собственно, он так и называется, однако, целостной картины будущей, или уже разработанной системы и в нём не представлено. Этот документ служит как-бы контейнером для отдельных прецедентов, функциональных и нефункциональных требований, увязка требований в единую стройную систему не предполагается.

-       "Архитектурный документ" – описание классов и компонентов ПО, показывает, в том числе, какие компоненты будут ответственны за реализацию требований, но уже в пространстве программного обеспечения, а не бизнеса.

Налицо отсутствие необходимого и достаточного описания разрабатываемой системы, из которого можно понять процессы работы системы, и, тем более, взять на сопровождение без проведения реверс инжиниринга ПО.

Это, на мой взгляд, является одной из основных причин, по которым программисты скептически относятся к программной документации, порождаемой аналитиками, и придерживаются принципа: "материализм это код" (цитирую слова коллеги – начальника отдела программирования).

Предположим, в целях дальнейшего обсуждения, что мы пытаемся обрести единый документ, в котором соберём все требования к системе и будем сопровождать её в дальнейшем, пусть это будет документ "Техническое задание" (ТЗ), представляющий симбиоз ТЗ в соответствии с ГОСТ 34 и SRS по RUP.

Как структурировать требования?

В связи с тем, что основной упор современные методики управления требованиями делают на управлении требованием как самостоятельным объектом, данный вопрос рассматривается не в первую очередь, регламентируется лишь структура разделов документа SRS, конкретное наполнение отдаётся на откуп пользователю.

В результате, в ТЗ ориентируются лишь избранные сотрудники – аналитик, который его разработал, заказчик, который согласился с текстом и понимает, как он устроен и, может быть, программист, которого заставили прочитать ТЗ и уведомили, что все изменения к ПО будут передаваться в дальнейшем как изменения к этому тексту.

При этом если кто-то другой захочет понять - как работает система (не только с точки зрения интерфейса), то к аналитику ему стоит обращаться в последнюю очередь, т.к. структура в которой представлены требования и пространство в котором "работает" аналитик очень слабо бьётся с автоматизируемым бизнесом и с разработанным программным обеспечением.

Единственное разумное, что предлагается в литературе посвящённой управлению требованиями – это функциональная декомпозиция, да и то, предлагают с оглядкой, поскольку методология SADT считается морально устаревшей.

Как связывать требования?

Многие требования связаны – непреложный факт и если, скрепя сердце, иерархические связи мы поддержим с использованием функциональной декомпозиции, то прямые связки сможем реализовать только с помощью механизма трассировки, реализованного в системах управления требованиями или прямыми ссылками в тексте. Таким образом, аналитик должен установить необходимые ссылки вручную, хотя, большинство ссылок между функциональными требованиями можно получить автоматически, исходя из связей по данным или последовательности выполнения функций.

 Как описать логику пользовательского интерфейса в ТЗ?

Это одна из самых трудно решаемых проблем, с которыми мне приходилось сталкиваться при разработке ТЗ, опробованные варианты и их недостатки перечислю:

-       макеты форм в MS Visio – очень хороший вариант для понимания и обсуждения, но совершенно не сопровождаем – после разработки реального интерфейса, разработанную в Visio форму часто выбрасывают;

-       описание модели иерархии форм и управляющих элементов GUI в виде модели классов, например, в Rational Rose, задача достойная как упражнение для оттачивания навыков объектного моделирования, результат годится только для того, чтобы окончательно разозлить программистов;

-       функциональное описание иерархии форм и управляющих элементов интерфейса (controls) в Idef0 – интерфейс можно описать достаточно подробно, однако требуются значительные трудозатраты аналитика, что в случае сжатых сроков разработки ТЗ может быть неприемлемым;

-       моделирование процесса работы с формами и элементами форм в виде сценариев, например, Idef3, - получаются достаточно интересные модели, однако, как и в случае модели классов – это лишь способ самовыражения аналитика.

Как описать разграничение прав доступа?

Определить права доступа к данным? Но при разработке ТЗ результирующая физическая модель данных ещё недоступна.

Определить права на формы и элементы GUI? Это традиционный способ, многие системы именно так и разрабатываются впоследствии, однако, с точки зрения безопасности этот способ не надёжен и может привести к наличию обходных путей.

Определить права на функции реализуемые в системе? Встаёт вопрос, – на какие, если на все, то описание прав и реализация такого подхода будут неэффективны. 

Как описать работу в многопользовательском режиме?
...

Концепция необходимого и достаточного ТЗ

Поиск ответов на поставленные в предыдущем разделе вопросы и апробация различных вариантов решения, позволили сформулировать принципы разработки документа "Техническое задание", которое является необходимым и достаточным для разработки на его основании программного обеспечения.

Что такое необходимость ТЗ?:

Все сведения, содержащиеся в Техническом задании должны быть необходимы для разработки ПО, т.е. они содержат информацию, относящуюся исключительно к устройству разрабатываемой системы и не содержат как "воды", так и, например, детального описания физической модели данных.

Что такое достаточность ТЗ?

Сведения, представленные в Техническом задании должны быть достаточными для разработки программного обеспечения либо "с нуля", либо с использованием существующих архитектурных фреймворков.

При этом:

-       ТЗ должно обеспечивать возможность исключения взаимодействия заказчик-программист, по крайней мере, до выхода первого прототипа ПО, в частности, это означает, что заказчик понимает из ТЗ как будет работать система, а программист понимает, как разработать такую систему, причём и заказчик и аналитик и программист "говорят на одном языке";

-       ТЗ должно содержать некоторую логическую модель будущей системы, реализуемость которой должна быть доказуема.

Понятие "операция"

Связующим звеном, или даже универсальным понятием, которое позволило организовать диалог заказчики – аналитики – программисты на одном языке, а также увязать в единую картину различные технологические фрагменты управления требованиями и разработки программного обеспечения, стало определение понятия "операция".

Определение:

Операция (в данном контексте подразумевается "Тип операции") - любое законченное преобразование данных, предоставляющее "бизнес-полезный" результат, и вызываемое некоторым внешним событием (вызов из интерфейса, получение сообщения и т.д.).

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

Операция - выделенная на логическом уровне описания и материализованная на физическом уровне деятельность, имеющая бизнес-полезный результат.

Возможен вопрос, чем отличается это понятие от прецедента?

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

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

Примеры операций:

-       сохранение файла подготовленного в текстовом редакторе;

-       публикация отчётных данных;

-       загрузка данных из внешнего источника, в целях последующей обработки в системе;

-       выставление счёта;

-       авторизация в системе и т.д..

Операция может включать в себя некоторый сценарий действий пользователя, например, при загрузке файла данных от внешнего источника это могут быть следующие шаги:

1.      выбор оператором каталога и файла для загрузки;

2.      загрузка файла системой;

3.      формирование системой проверочного отчёта;

4.      проверка оператором результатов загрузки;

5.      подтверждение или отказ оператора от загрузки данных. 

Какой результат считать бизнес-полезным? – вопрос, на который дают ответ заказчики и аналитик, возможные варианты:

-       получение  финальных результаты обработки данных;

-       получение промежуточных данных, которые могут потребоваться для отдельной публикации, или необходимы в других системах;

-       загрузка данных из внешних источников, если процессы загрузки и обработки данных разнесены во времени.

Как показала практика, заказчик хорошо понимает существо операций, так как заказчику как ни кому другому известна бизнес-полезность результата, а также необходимые контрольные точки в процессе обработки данных.

Кроме того, понятие операция хорошо ложится на традиционные требования вида: "я нажимаю кнопку и происходит вот это:..." и "ещё у меня должна быть такая кнопка, чтобы:..." часто, за этими требованиями лежат готовые операции.

Зачем нужны операции?

Оказывается, с помощью операций легко представить структуру любой системы, используя понятие "Операционного графа":

Операционный граф - граф зависимости операций:

-       узел графа соответствует уникальному типу операции;

-       направленная связь из одного узла в другой - означает связь по данным между операциями.

Таким образом, просто на бумаге, используя выявленные операции можно нарисовать операционный "скелет" системы, при этом узлы графа будут чётко соотнесены с автоматизируемым бизнес-процессом.

Собственно, вот он – основной результат, чёткое и непротиворечивое понимание всеми заинтересованными сторонами того что будет делать система и как она устроена на логическом уровне.

Ответы на поставленные вопросы

Итак, ответим на поставленные ранее вопросы.

Что и как будет делать система?

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

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

Как описать логику пользовательского интерфейса в ТЗ?

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

При описании GUI аналитик должен будет описать:

1)      интерфейс вызова операций на исполнение и перехода между операциями;

2)      для каждой операции - интерфейс работы пользователя в рамках выполнения сценария операции.

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

Хотя, если в компании используется специализированный операционный  программный фремворк, возможно и чудо:

- интерфейс представлен в виде древовидной структуры операционного графа (плана выполнения операций), выбирая отдельный узел графа, пользователь получает доступ к интерфейсу исполнения выбранной операции. Исполнение отдельной операции становится доступным, когда выполнены все исходные операции, например, загружены все исходные данные. 

Как описать разграничение прав доступа?

Очень просто – с помощью определения прав пользователя на исполнение всех типов операций, определённых в системе.

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

Как описать работу в многопользовательском режиме?

Описывается матрица взаимных блокировок при исполнении операций, при этом учитываются информационные блоки, которые обновляются при исполнении операций.

Опять же, если операционный подход используется при разработке ПО, при инициации исполнения каждой операции, проверяется возможность её исполнения на основании матрицы блокировок и информации о текущих исполняемых операциях.
Возможно, также, реализовать более сложные алгоритмы определения доступных к исполнению операций, тогда интерфейс пользователя становится динамическим или "интеллектуальным".

Оставшиеся вопросы "Как структурировать требования?" и "Как связывать требования?" рассмотрим в следующем разделе.

Структура операционно-ориентированного операционного ТЗ

Операции хорошо, но где же алгоритмы, сценарии и данные?

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

Как структурировать требования?

Операционно-ориентированное техническое задание включает в себя следующие основные блоки:

                           I.          Краткая характеристика системы

·        краткое описание автоматизируемого бизнес-процесса, или ссылка на документ, описывающий БП;

·        краткое описание реализуемого операционного графа с привязкой к бизнес-процессу.

                         II.          Описание операционного контура

·        описание операционного графа;

·        описание каждой отдельной операции, включая:

-  регламент выполнения;

-  ссылку на вызываемый сценарий, или функцию, описанные в блоке "Требования к функциям";

-  права на исполнение операции;

·        описание матрицы блокировок;

                       III.          Требования к функциям

·        в разделе описываются сценарии и отдельные функции, которые должны выполняться при исполнении операций;

·        сценарии и функции должны быть структурированы в виде иерархии функциональных блоков, организованных в соответствии с циклами обработки информации, реализуемых в системе;

·        в отдельный подраздел можно выделить описание стандартных функций, вызываемых в различных сценариях;

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

                       IV.          Требования к информации

·        в разделе описываются форматы данных, являющихся входами или выходами функций, описанных в блоке "Требования к функциям"

·        описание данных структурируется в виде иерархии потоков данных между функциональными блоками

Подробно обсуждение наполнения приведённых блоков предполагается провести в следующих статьях.

Как связывать требования?

"Идеальное" техническое задание должно включать в себя следующие основные ссылки (совсем в идеале – гиперссылки в тексте) между требованиями, которые происходят из следующих основных связей между операциями, сценариями, функциями и данными:

 

·        Операция

-   вызывает на исполнение сценарий;

-   вызывает на исполнение функцию;

·        Сценарий

-   вызывает на исполнение функцию;

·        Функция

-   вызывает на исполнение функцию;

-   использует входящие данные;

-   порождает/модифицирует исходящие данные;

·        Данные

-   используются в функции.

Данные ссылки могут быть сформированы автоматически, в случае использования в качестве основы для подготовки Технического задания специализированного ПО управления требованиями, которое обеспечивает поддержку ссылочную целостности по вызовам и по данным.

Нефункциональные требования

 Некоторые традиционные нефункциональные требования будут распределены по основным разделам ТЗ, приведённым выше, а именно:

-       требования к производительности логично отнести к операциям;

-       требования к программным интерфейсам переходят в раздел "Требования к информации";

-       требования к пользовательскому интерфейсу логично распределить между разделом "Описание операционного контура" и описаниями сценариев раздела "Требования к функциям"

 

Оставшиеся нефункциональные требования к языкам программирования, архитектуре, условиям эксплуатации, персоналу и т.п., организуются в традиционном выделенном разделе "Нефункциональные требования".

Чтоб не забыть формулировку

Операция (в контексте данного блога) - материализованная на логическом и физическом уровне деятельность, имеющая бизнес-полезный результат.
(завтра раскрою:)

От теории к практике (пример реальной разработки)

Архитектура системы: Oracle (данные + бизнес логика) + JSP на Сервере приложений + Internet browser.

Вся информация о структуре операций лежит в БД.

Идеальный операционный GUI, полностью формируемый на основании Операционного графа:

Сценарий работы пользователя выглядит следующим образом:

1. пользователь выбирает доступный узел графа, т.е. операцию, которую можно выполнить в данный момент;
2. пользователь задаёт параметры выбранной операции;
3. пользаватель инициирует исполнение операции;

Операции, расположенные выше по иерархии (зависимые от подчинённых), становятся доступными к исполнению после того, как будут выполнены все исходные операции (подчинённые в соответствии с графом).

Приведённая форма прорисовывается автоматически, на основании данных, внесённых в следующую достаточно простую физическую структуру:

Причём, обратите внимание, что в таблице OPERATION_GRAPH, присутствуют поля BEGIN_DATE и END_DATE, что позволяет менять набор операций системы с течением времени без перепрограммирования, а также возможность проводить операции для прошедших периодов.

Определения и модели

Операция (в данном контексте подразумевается "Тип операции") - любое законченное преобразование данных, предоставляющее "бизнес-полезный" результат, и вызываемое некоторым внешним событием (вызов из интерфейса, получение сообщения и т.д.).
Операции имеют иерархическую структуру и разделяются на две категории - листовая операция и контейнерная операция.

Листовая операция (ЛО) - операция, не включающая в себя других операций и порождающая набор данных, идентифицируемый уникальным номером (версии);

Контейнерная операция - операция, включающая в себя одну, или более подчинённых операций и не порождающая никаких версий данных, кроме как версий, порождённых подчинёнными ей операциями.

Версия (данных) - уникальный идентификатор (в рамках программной системы), идентифицирующий набор данных, порождённый в при проведении листовой операции.

Интервал версии - диапазон дат, для которого сформирован набор данных, порождённый соответствующей листовой операцией.

Набор объектов версии - набор объектов, относительно которых проводилась соответствующая листовая операция (например, это может быть набор договоров, относительно которых проводилась операция и т.п.)

Операционный граф - граф зависимостей типов листовых операций:
– узел графа соответствует уникальному типу листовой операции;
– направленная связь из одного узла в другой - означает связь по данным между листовыми операциями.

Фактический операционный граф - граф зависимостей между фактически проведёнными операциями, или, что эквивалентно, между версиями данных; строится на основе операционного графа и функции определения зависимости между листовыми операциями.

Функция определения зависимости между фактически проведёнными ЛО - в качестве входных параметров принимает номера двух ЛО и на основании:

1. типов соответствующих листовых операций;
2. операционного графа;
3. интервалов версий данных, сформированных ЛО;
4. наборов объектов версий;

- определяет наличие, или отсутствие связи между двумя заданными операциями.

ER-модель операций:

Сценарий проведения операции:

Вся идея целиком, пункты буду раскрывать последовательно

Движение — всё, цель — ничто

Начнём, пожалуй.

Итак, давайте разберёмся с названием "Операционно ориентированное программирование" (ООП), и его очевидном противопоставлении традиционной расшифровке ООП.
В 90-х годах все, в том числе и я были увлечены объектно-ориентированным подходом с благоговением читали Страуструпа и пытались переложить любые программы в логику взаимосвязанных классов, имеющих некоторые индивидуальные методы.
При этом, иногда, красота объектов, живущих в системе, затмевала то, чему должна быть посвящена система, а именно, автоматизации некоторой деятельности (бизнес процесса).

to be continued...

Introduction

Вот, решил таки завести свой блог, хотя долго сомневался...
В общем, хочу упорядочить свои идеи относительно методов моделирования информационных систем, процессов разработки тех. заданий и разработки программного обеспечения на основе моделей и ТЗ.