Практика и подходы к восстановлению требований к ИС

Источник: IBM Rational

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

Что такое "восстановление требований"?

В ходе своей работы консультанта, который в большей степени занимается сферой управления требованиями, очень часто приходится сталкиваться со словосочетанием "восстановление требований". Давайте посмотрим, что это за зверь и как с ним справиться.

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

Если взять второе определение, то восстановление "условий, которым должна удовлетворять создаваемая система" в принципе не нужно, система-то уже есть. А вот если посмотреть на первое определение, то тут ответ далеко не так очевиден. Нужно ли для функционирующей системы иметь "спецификации наблюдаемого поведения"? В той или иной степени ответ "Да".

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

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

Как мы попали в эту ситуацию и почему хотим выбраться?

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

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

Как вы поняли, список отсортирован по возрастанию сложности процедуры восстановления.

Первый вопрос, который нужно поставить перед собой в случае недостатка документации, следующий: "А нужно ли вообще её восстанавливать?"

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

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

Представленные списки не претендуют на полный охват причин и целей задачи восстановления проектной документации. Но если вы читаете эту статью, то, видимо, по какой-то причине с этим столкнулись. Если внимательно присмотреться к последнему списку, то в нем явно или не явно возникают вопросы: "Для кого мы хотим восстановить требования?", "Кто будет пользоваться восстановленной документацией?". Это могут быть: служба поддержки; команда проекта, развивающего систему; потенциальный клиент.

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

Если для вас стало окончательно ясно, что требования восстанавливать нужно, то встает следующий вопрос:

Какой объем требований достаточен?

Ответ на этот вопрос следует непосредственно из ответа на вопрос "Кто будет потребителем?".

Если это служба поддержки, то для неё скорее всего будут важны следующие аспекты:

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

Если это команда проекта, развивающего систему, то для неё будут важны вопросы:

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

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

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

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

Сразу же хочу определиться. Архитектурный взгляд на систему, несомненно, является одним из самых важных в комплекте проектной документации. Но… с точки зрения RUP это отдельная дисциплина, поэтому касаться её в этой статье мы не будем. Оставим лишь "спецификации наблюдаемого поведения системы". Документацию по установке и настройке анализируемой системы также оставим за рамками статьи. Эти артефакты относятся не к проектной, а к пользовательской документации.

Теперь нужно определить:

Какие нам нужны артефакты?

Рассмотрим набор артефактов дисциплины "Управление требованиями" из RUP. Это:

Запросы заинтересованных лиц;
Концепция системы;
Глоссарий;
Дополнительные спецификации;
Модель прецедентов;
Описание прецедента (раскадровка);
План управления требованиями;
Атрибуты требований.

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

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

Глоссарий - очень полезный артефакт. Удобнее иметь один глоссарий на предметную область, а не отдельный документ на систему.

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

Модель прецедентов - если планируется дальнейшая разработка системы, то модель нужна.

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

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

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

Кроме артефактов требований может оказаться полезным восстановить некоторые аспекты бизнес-модели:

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

Немного о ГОСТ

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

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

С точки зрения RUP, разделы 5, 6, 7 относятся к другим дисциплинам: управление проектом, тестирование. Для уже существующих систем проектно-экономические показатели, планы и порядок тестирования восстанавливать не имеет смысла. Информация, содержащаяся в разделе "Общие сведения", обычно содержится в контрактных документах. Для существующих систем она не требуется. Подытоживая, можно сказать, что в Техническом задании следует восстанавливать только те разделы, которые описывают свойства анализируемой системы. Причем в том объеме, который востребован потребителем этого документа.

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

Как управлять восстановлением требований

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

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

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

Непосредственно проект не принесет прибыли, так как он внутренний. Однако другие проекты (или сервисы), используя его результаты, должны сократить издержки.

Нужно отметить, что восстановление требований нужно организовывать как отдельный проект, а не встраивать его в какой либо проект по разработке. Почему? У этих проектов разные цели. Кроме того, легче управлять ресурсами. Фактически такой проект мы заканчиваем после выполнения двух фаз RUP: Начало и Уточнение.

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

Если решение о начале работ принято, то проект переходит в фазу Уточнение. Удобнее всего начать с восстановления диаграммы прецедентов. Источником информации для этой диаграммы являются: Руководство пользователя, Руководство администратора, меню системы, список ролей в системе (например, в настройках системы).

На основании диаграммы прецедентов восстанавливается Концепция. Есть несколько аспектов этой работы. Если вы восстанавливаете документацию к большому количеству небольших утилит для последующего переноса их на новую платформу, то имеет смысл группировать их и создавать Концепцию на группу. Группировка производится таким образом, чтобы в последующих проектах разработки вся группа стала частями одной будущей системы. При восстановлении Концепции к большой системе можно разбить её на подсистемы и восстанавливать Концепцию для каждой подсистемы. Правило разбиения остается таким же, как и для проектов разработки: в документе должно быть описано от 25 до 99 функциональных возможностей. В ходе работы над Концепцией необходимо, насколько это возможно, понять и зафиксировать бизнес-цели, решаемые при помощи анализируемой системы.

Параллельно с восстановлением Концепции можно восстанавливать Дополнительную спецификацию. В этом артефакте следует фиксировать фактические параметры функционирования системы: аспекты надежности, производительности и прочие нефункциональные свойства системы. Источником данных для этого документа может быть статистика, замеры производительности, результаты нагрузочного тестирования и т. д. Этот документ может быть полезен службе поддержки и потенциальным клиентам. Разработчики могут использовать этот документ для оценки изменения параметров системы после доработки.

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

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

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

Витязь на распутье (или кто всем этим займется?)

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

Принимаем на работу нового работника и выделяем его для этого проекта на полную загрузку. Плюс в таком подходе - специалист разбирается в том, как система функционирует и получает необходимую квалификацию. Остальные работают в прежнем режиме. Вернее пытаются работать, так как выделенный для этой работы новичок неизбежно будет вынужден прибегать к консультациям более опытных товарищей. Кроме того, новый специалист не понимает, почему то или иное требование возникло. Он не видит проблем, стоящих за решениями, реализованными в системе. Это минус подхода. Качество выполнения работы зависит от количества времени, отнятого у других. Даже если исполнителем является не вновь принятый новичок, то один специалист вряд ли будет одинаково хорошо знать всю большую систему (или большое число небольших утилит).
Выделяем на такой проект часть времени имеющихся специалистов. Например, по плану на это отводится пять часов в неделю. Хочу отметить, что расходование этого ресурса на другие задачи должно быть уменьшено на такое же количество времени. Плюс в таком подходе - вся проектная команда сбалансированно увеличивает компетенцию по анализируемой системе. Ещё одно положительное качество при таком подходе - можно восстановить требования более глубоко, особенно если документацию восстанавливает та же команда, которая разрабатывала ПО. Минусом при таком подходе является отвлечение специалистов от других проектов. При описываемом подходе есть возможность более гибко подходить к планированию процесса. Можно производить как полное восстановление проектной документации, так и частичное. При частичном - восстанавливается тот объем требований, который необходим для дальнейшей разработки. Сначала могут быть восстановлены старые требования, на их основе формируются новые и после этого производится реализация. Например, если дорабатывается модуль системы, то сначала восстанавливаются требования к нему, которые не изменятся в ходе доработок, затем формируются требования по доработке.
Привлечение к работе сторонних аналитиков. Единственным плюсом в такой схеме является то, что специалисты не отвлекаются на проект восстановления. Минусов же гораздо больше - обычно этот подход дороже, чем использование внутренних ресурсов; компетенции не сохраняются в коллективе; как и в первом варианте, отвлечение на консультации гарантировано.

Однако все три подхода имеют право на жизнь.

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

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

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

Хуже граблей только детские грабли. Ошибки и как их избежать

Наиболее часто встречаются следующие ошибки.

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