Опыт применения СППР для формирования документа «Описание проектного решения»

Меня зовут Ольга Лазорик, я аналитик компании WiseAdvice-IT. Я расскажу, как с помощью СППР формировать такой документ, как «Описание проектного решения».

Доклад будет сугубо практический – я расскажу свой опыт использования СППР в работе аналитика. Надеюсь, это вдохновит кого-то на использование СППР в дальнейшем.

У меня нет задачи рассказать о том, что СППР – это хорошо или плохо. Я знаю, что на этот счет сломано немало копий и пока система, возможно, для многих не очень понятна и проста. Но если СППР у вас уже есть, это может быть одним из удобных инструментов для написания проектной документации.

Презентуя систему СППР, фирма «1С» дает ей у себя на сайте следующее определение:

«Система проектирование прикладных решений (СППР) предназначена для проектирования прикладных решений (конфигураций) на платформе 1С:Предприятие и ведения технической документации проекта».

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

Плюсы и минусы СППР

Система СППР применима в различных функциональных направлениях – она нужна:

• Руководителям проекта – для сбора требований и проверки системы на соблюдение целостности.

• Разработчикам – чтобы проектировать систему согласно собранным требованиям.

• Техническим писателям – чтобы формировать документацию.

• Тестировщикам – чтобы получать документацию по тестируемой функциональности. При этом не везде есть технические писатели или тестировщики – часто на проекте эти функции сочетает в себе аналитик.

• Ну и внедренцы могут ознакомиться с той системой, которую они внедряют.

На мой практический взгляд, один из плюсов СППР – это то, что у всей команды есть доступ к модели системы и к ее объектам. Разработчик видит в задаче собранные по ней требования, и в эту же задачу при необходимости может зайти аналитик – посмотреть и уточнить требования.

Таким образом СППР связывает участников всей команды и объединяет их. Но здесь есть свои особенности, о которых я дальше расскажу.

Перед тем как готовить доклад я опросила коллег в сообществе, в чем они обычно пишут «Описание проектного решения»:

• Большинство опрошенных ответили, что используют Word – это самый привычный инструмент, когда в компании есть какой-то шаблон или бланк (так называемая «рыба»), и по нему люди описывают, как проектное решение будет выглядеть.

• Маленький процент опрошенных пишет документацию в СППР.

• И некоторые используют такой вариант как Confluence.

Я работала в разных проектах, и почти всегда в том или ином виде писала ОПР в Word. Это действительно один из самых привычных, доступных инструментов – у всех есть MS Office.

Но заполнять объемную документацию в Word неудобно – стандартной структуры для быстрой навигации не хватает. Когда у нас серьезная доработка или разработка, бывает сложно ориентироваться в объемном многостраничном документе – на моей практике встречались описания до 500 страниц. В таком документе сложно находить какие-то кусочки, особенно те, которые нужно поправить.

Мне кажется, что в сравнении с Word, у СППР есть определенные плюсы:

• Самый главный плюс – это логичная структура объектов системы. Мы свой будущий документ строим в СППР как пирамидку из кубиков – что это за кубики, я потом подробнее расскажу.

• Все эти объекты друг с другом взаимосвязаны.

• Нам легко изменить какой-то один кусочек. Если изменилось какое-то требование, нам не нужно искать его в Word по ключевым словам – мы открываем в нашей структуре конкретное требование с конкретным номером, меняем его, переформировываем документ и получаем профит. В Word это сложнее.

Но и сложности, конечно, тоже есть:

• Во-первых, это непривычно – функциональность описания проектного решения в СППР на первый взгляд выглядит довольно сложно. Там очень много разных объектов, которые в разных местах системы называются по-разному. Кроме того, у разных версий СППР терминология тоже разная – у нас используется доработанная СППР 1.1.

• Не всегда доступно – не у каждого на проекте есть СППР, и не все могут реализовать для нее возможность формировать нужную документацию автоматически.

Но если уж так сложилось, что у вас на проекте есть СППР, или заказчик вас просит формировать документы в СППР, то, по-моему, это один из наиболее удобных инструментов. Позже мы увидим это на примере моего документа.

Одна из коллег поделилась со мной историей, что у нее был заказчик, который просил одновременно предоставлять документацию в Word, в Excel с определенной структурой и одновременно дублировать это все в СППР. Понятно, что это совсем неудобно, но мы говорим про создание документации в идеальной среде, когда мы в СППР начинаем и в Word ничего не ведем.

Так вышло, что я на своем проекте была первопроходцем по созданию документов в СППР. И несмотря на то, что у нас уже была пошаговая инструкция, мне пришлось отдельно проводить коллегам мини мастер-классы и писать мини-инструкции в понятном неформальном варианте. Потому что в официальной документации, к сожалению, не очень понятно, что СППР вообще от нас хочет – что подразумевается под названиями «Функция», «Задача автоматизации» и так далее.

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

Отдельно хочу сказать про логическую модель системы. Это тоже определения с сайта вендора:

• Логическая модель системы строится с учетом процессов, которые мы автоматизируем.

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

• И логическая модель всегда соотносится с объектами метаданных конфигурации.

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

Структура ОПР

Документ «Описание проектного решения» в схематичном представлении выглядит вот так.

• Основой всего служит проект. Проект в СППР – это конфигурация, которую мы описываем.

• На основании проекта создаются целевые задачи. Целевая задача – это конкретно задание, что нам нужно сделать. Мы внедряем новую функциональность, и конкретная целевая задача может называться «Создание дополнительного отчета», «Доработка системы» и т. д. В моем случае целевая задача называлась «Создание новых и доработка существующих контрольных процедур по функционалу биллинга».

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

• В техническом проекте мы описываем архитектуру и на его основании создаем проектное решение, которое также называется функция или задача автоматизации – как я уже говорила, в СППР не очень очевидная терминология и структура для начинающих. И в рамках функции описываем ту функциональность, которую внедряем или дорабатываем. У нас будет:

  • описание функции;

  • схема функции;

  • элементы функции;

  • и у нас еще добавлено описание алгоритма и шаги функции

Это общая картинка для понимания, из чего формируется документ «Описание проектного решения» – дальше будут конкретные скриншоты с описанием каждого из этих кубиков.

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

Целевая задача

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

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

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

Основная вкладка здесь – это «Описание и результат», здесь в текстовом поле мы в общих словах описываем, чего хочет пользователь. Переносим сюда тот запрос, который пользователь сформулировал в системе Service Desk или информацию из протокола сбора требований. В данном случае целевая задача создавалась на основании ЗНИ, запроса на изменение от пользователя.

Список требований

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

Эти требования уже формализованные – мы их пишем нетехническим языком, без употребления специфических терминов, так, как их написал бы сам пользователь.

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

Вот так выглядит карточка требования – в ней мы тоже заполняем разные поля.

• Поле «Задача автоматизации» – это как раз-таки функция, которую мы будем рисовать, к ней я чуть позже вернусь;

• «Формулировка» – краткая формулировка;

• «Целевая задача» – ссылка на целевую задачу;

• «Раздел проекта» – в данном случае «Бухгалтерский и налоговый учет»;

• «Код требования» – присваивается автоматически;

• и на вкладке «Подробное описание» описываем требование пользователя его словами.

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

Технический проект (техническое решение)

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

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

• первое звучало как «Создание нового функционала»;

• второе – «Доработка старого функционала»;

• третье – «Создание отчета» и так далее.

В техническом решении в первую очередь заполняется вкладка «Концепция» (у нас она называется «Архитектура проекта») – здесь мы в терминах объектов метаданных описываем то, что напроектировали.

Обычно эту закладку заполняет разработчик, который реализует это техническое решение, но в данном конкретном случае у нас с ним возник небольшой спор. Он сказал: «Я не буду это писать, описывай сама. Ты знаешь объекты метаданных, знаешь, как это работает. Вот так в отчете выглядит текст запроса – я тебе расскажу, что здесь происходит, а ты опишешь». Поэтому здесь я описала эту функциональность сама.

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

Функции

Следующий объект СППР, достаточно крупный – это функция, где мы уже будем рисовать функциональную модель.

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

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

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

В первый раз это действительно может быть тяжело. Поэтому если вы решите все-таки заняться формированием документации в СППР, я советую вам определенное время уделить на то, чтобы разобраться в структуре системы, а потом уже ее описывать.

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

В карточке функции есть несколько вкладок.

Первая вкладка – «Описание», здесь мы описываем функциональность. Причем делаем это уже как аналитики, чтобы человек, когда открыл наш ОПР, мог прочитать не в терминах метаданных и реквизитов из конфигуратора, а функциональным языком: из какого регистра берутся данные, какие в отчете колонки и так далее.

На закладке «Схема функции IDEF0» мы описываем формирование отчета в нотации IDEF0. На этой картинке:

• слева находятся некие входящие данные – мы собираем колонки из регистров сведений, регистров накопления и регистра бухгалтерии «Хозрасчетный»;

• в центре находится сама наша функция формирования отчета;

• и на выходе получаем то, что хотели – объект метаданных «Отчет».

По сравнению со схемами бизнес-процессов в BPMN, схемы функций в нотации IDEF0 выглядят очень просто – при их отрисовке используются только квадратики и линии, больше ничего. Здесь нет кружков или разных форм, как в BPMN, нет расцветок. Всегда один цвет, только квадратики и линии. Важно только то, где конкретно находится тот или иной квадратик.

Мы можем создать здесь квадрат с надписью «Регистр бухгалтерии Хозрасчетный», и на вкладке «Описание элементов системы» автоматически появится строка, которая описывает «Регистр бухгалтерии Хозрасчетный».

В идеале, если система проектируется в СППР с нуля и описания метаданных заполнены, при связывании этой строки с объектом через поле «Гиперссылка», его описание подтянется сюда в поле «Описание элемента схемы» и будет подсвечено синим цветом. Здесь видно, что у одного из объектов метаданных описание оказалось заполнено, а для остальных мне пришлось прямо здесь эти элементы схемы описывать.

Здесь показаны скриншоты для вкладок «Описание алгоритма» и «Шаги функции» – они небольшие, и я уместила их на один слайд.

Зачем нужны эти вкладки?

Как вы уже могли заметить, в разных объектах СППР мы формируем описание разным языком:

• В «Техническом решении» мы делаем описание для технического сотрудника, чтобы разработчик мог открыть документацию и увидеть, как описана архитектура проекта.

• В «Функции» мы даем описание функциональным языком, чтобы аналитик понял, как это работает.

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

• Во вкладке «Описание алгоритма» мы очень коротко описываем, что именно делает пользователь для того, чтобы наша функциональность сработала. В данном случае написано:

  • где в интерфейсе будет находиться этот отчет – какой у него раздел и подраздел;

  • какой профиль доступа нужен пользователю для запуска отчета;

  • и какие шаги нужно сделать для формирования отчета – открыть форму отчета, установить настройки и сформировать отчет.

• Во вкладке «Шаги функции» описываем все это пошагово – это потом войдет в документ «Описание проектного решения», там будет раздел «Шаги для пользователя».

Выгрузка ОПР

Переходим к финальному этапу – к формированию документа.

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

Нажимаем кнопку «Печать» и выводим документ на печать:

• либо в виде функциональной спецификации;

• либо полный вариант со всеми приложениями.

На выходе получается огромный вордовский документ, в котором все наши заполненные вкладки сформировались в тот или иной подраздел. Слева на скриншоте показана его структура:

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

• Во втором разделе выводятся подробные описания всех требований.

• В подразделе «Роли и полномочия» либо выведется текст по умолчанию «В проектном решении роли и полномочия не изменяются». Либо, если мы добавили какую-то новую роль, там будет написано, что добавлена роль для пользователя такая-то.

• И самое основное – третий раздел, который называется «Описание задач автоматизации», здесь мы видим структуре документа наши функции, то, как мы их рисовали:

  • Входная информация – это то, что было на схеме: регистр накопления такой-то, регистр сведений такой-то, регистр бухгалтерии «Хозрасчетный».

  • Обработка информации – описание самой функции с точки зрения аналитика.

  • Выходная информация – описание отчета для пользователя.

  • И описание алгоритмов – те пошаговые действия, которые выполняет пользователь.

• Если бы у нас было много функций, у нас была бы объемная структура, которая разворачивалась бы в «Комплекс задач Формирование отчета», «Комплекс задач Доработка контрольных процедур», «Комплекс задач Создание новых контрольных процедур» и т.д.

• В раздел «Архитектура и проектные решения» выводятся описания из технических решений, которые составлял разработчик в разрезе объектов метаданных.

• В приложениях выводятся все документы, которые мы добавляли как вложения к требованиям.

Заключение

С точки зрения написания проектной документации у СППР есть множество плюсов перед Word:

• Наверное, только в вакууме можно полностью описать проектное решение до его разработки. Для внесения изменений в Word нам придется искать по ключевым словам, по содержанию, где же мы это описывали. И если вести учет изменений проекта в СППР, то когда в процессе разработки что-то меняется, добавляются новые объекты, мы просто заходим в описание функции, меняем гиперссылку одного объекта на другой, сохраняем и получаем новый документ.

• Важно, что это изменение точно не останется незамеченным – мы его зафиксируем для всей команды. Если мы какую-то функциональность изменили, это фиксируется в целевой задаче.

• Вордовский документ может потеряться, вы можете позабыть, что в нем что-то менялось. А в СППР все изменения будут храниться, и любой человек – разработчик или тестировщик – может зайти и посмотреть, что изменили.

В этом, на мой взгляд, удобство СППР.

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

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

Вопросы и ответы

Вы сказали, что формировали проектное решение на базе ЗНИ, в СППР у вас уже был проект, и это только одна его целевая задача. А каким образом реализовать в СППР этот подход при внедрении систему с нуля? Например, у нас полноценно внедряется несколько блоков – нам нужна одна целевая задача, и все требования по всем блокам будут формироваться в ней?

Если посмотреть, как фирма «1С» у себя на сайте презентует СППР, то там показано как в целом строится модель системы – мы создаем некие блоки, подблоки, и на их основании уже создаем конкретные целевые задачи. Например, у нас есть проект, и в нем блоки «Бухгалтерский и налоговый учет», «МСФО», «Казначейство», «Бюджетирование».

При этом в каждой компании структура документации разная. На этом проекте мы формировали функциональные спецификации, причем в подсистеме «Расчет себестоимости» могли быть разные функциональные спецификации, которые описывают ту или иную функциональность. И у нас целевые задачи могли создаваться отдельно под различные требования к документации.

Как обстоит дело с версионностью объектов, как СППР хранит историю изменений?

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

Структура результирующего документа, который вы печатаете, жестко зашита в СППР? Она там настраивается или она вообще разрабатывается с помощью разработчиков 1С?

Она жестко зашита и дорабатывается – мы не настраиваем ее в режиме 1С:Предприятие.

И если в разных проектах могут быть разные требования по шаблону документа, тогда этот шаблон придется переписывать под проект под заказчика, правильно я понимаю?

Да.

Как вы считаете, с точки зрения заказчика у СППР есть перспективы применения на этапе эксплуатации?

Как раз тот пример, который я рассказывала – это жизнь в эксплуатации. Это проект техподдержки. Запросы на изменения интегрируются из Service Desk и на их основании создаются уже задачи на доработку.

В связи с этим следующий вопрос. У нас и решение может меняться, обновления какие-то прилетать. Это тоже необходимо каким-то образом отражать в системе? И какова эта трудоемкость?

Конечно, СППР нужна на проекте не только для того, чтобы аналитики могли формировать свою проектную документацию.

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

Каждое обновление разработчик всегда отражает и согласует в СППР, в релиз выпускают только после согласования в СППР.

Сейчас все чаще в реализации IT-продуктов используются гибкие методики – Agile, Scrum и так далее. Насколько использование СППР сочетается с гибкими методиками?

На мой взгляд, этот вопрос очень спорный и требует взвешивания со всех сторон. В самом начале я говорила, что не берусь оценивать роль СППР на проекте. Я не функциональный архитектор и не руководитель проекта. Конкретно я могу рассказать: «Если СППР у вас уже есть, давайте ее использовать вот так».

Что дает СППР – мы быстрее вносим в проект изменения по запросам? Насколько этот инструмент повышает эффективность реализации задач, если у нас сейчас большой дефицит ресурсов?

На мой взгляд, это зависит от масштаба – СППР нужна, если мы внедряем большую систему. Она увеличивает не скорость разработки, она увеличивает качество взаимодействия между командой. Часто это важно.

Как внедрить СППР для поддержки уже существующей системы? Мы должны полностью отразить в СППР текущее состояние системы и потом уже через ЗНИ догонять какие-то новые доработки? Или мы можем там сразу описывать новые доработки, а текущий стейт не закладывать? Как правильнее?

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

Поэтому на практике, как раз в моем случае, мы в СППР описываем только доработки, и, если нам не хватает каких-то взаимосвязанных объектов, просто на ходу их дописываем. Наверное, это не совсем правильно, но, по крайней мере, жизненно. И это работает.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.