Структурная декомпозиция работ проекта

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

Структурная декомпозиция работ (СДР или WBS - Work Breakdown Structure) – это представление проекта в виде иерархической структуры работ, полученной путем последовательной декомпозиции. СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей.

Благодаря структурной декомпозиции работ менеджер проекта имеет:

· точное описание содержания работ;

· точное определение объема работ;

Предназначение СДР

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

СДР обеспечивает выявление работ, необходимых для достижения целей проекта. Каждый следующий уровень декомпозиции обеспечивает последовательную детализацию содержания проекта, что позволяет производить оценку выполненных объемов работ, освоенных денег и выполнения по срокам. На нижних уровнях пакетам работ соответствуют сравнительно меньшие объемы работ. Это упрощает оценку процента выполнения и дает возможность более четко определять действия, необходимые для достижения целей проекта.

Разработка СДР имеет две основные цели :

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

2. обеспечение отсутствия работ, не связанных с реализацией проекта.

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

На основе СДР выполняются следующие процесс:

1. определение работ,

2. планирование ресурсов,

3. оценка стоимости,

4. бюджетирование,

5. определение рисков.

Рис. 2‑1 Взаимодействие СДР с процессами реализации проекта (PMBOK Guide 1996)

Таким образом, СДР является основой:

Комплексного план-графика проекта

· Отчетности о выполнении проекта – с помощью СДР определяется состояние проекта и выдается в различные формы отчетности. Например, по стадиям жизненного цикла проекта; по результатам; по пакетам работ. Отчеты могут содержать данные по стоимости, срокам, рискам, объему, трудоемкости и качеству выполняющегося проекта или по сравнению с предыдущими аналогичными проектами (с такой же структурой).

Комплексного контроля изменений

Управления содержанием проекта

Организации взаимодействия между участниками проекта

Формирования организационной структуры

Разработка структурной декомпозиции работ

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

Провести декомпозицию и составить СДР, по мнению некоторых авторов, очень легко: «Прежде всего, следует разбить проект на несколько подпроектов. Каждый из подпроектов, в свою очередь, может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нижний уровень детализации».

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

· Что нужно сделать (определить продукты проекта);

· как это нужно будет делать (определить технологические этапы проекта);

· кто это будет делать (определить исполнителей, соисполнителей, субподрядчиков);

· кто и в какой форме будет оплачивать работы (определить, какие и с кем будут заключены контракты).

На какие подпроекты нужно разбить исходный проект? Что будет удобнее увидеть на первом уровне декомпозиции – компоненты конечного продукта проекта (программные, технические, информационные) или технологические этапы производства (концепция, ТЗ, проектирование)? А может быть, удобнее сгруппировать работы по исполнителям или заказчикам? Таким образом, мы подошли к трем вариантам построения СДР:

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

https://pandia.ru/text/80/308/images/image003_93.gif" width="675 height=526" height="526">

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

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

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

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

Системный подход к СДР

Если при разработке СДР руководствоваться теорией управления системами, то можно рассматривать проект как процесс превращения входных элементов (ресурсов, денег, трудозатрат) в выходные (результаты проекта).

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

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

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

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

Этапы разработки СДР

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

Основной процесс разработки СДР состоит из следующих шагов:

Первый шаг

определение конечных результатов проекта

Второй шаг

определение основных пакетов работ

Третий шаг

Четвертый шаг

анализ и усовершенствование СДР.

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

Если проект большой, СДР может иметь довольно общий характер. Можно остановиться на самом нижнем уровне, который отслеживает руководитель проекта. Этот уровень, напомним, принято называть пакетом работ. Следует учитывать, что, начиная с этого уровня, другие менеджеры, занятые на проекте, должны осуществить более подробное разделение проекта на части (подпроекты) до уровня элементарных работ.

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

Правила разработки СДР

При разработке СДР необходимо принимать во внимание следующие основные правила :

· Каждый элемент СДР должен обеспечивать достижение измеримого результата.

· Каждый элемент СДР должен агрегировать все подчиненные элементы.

· Результаты должны логически декомпозироваться до уровня, на котором можно определить, как они будут достигаться (проектирование, поставки, заключение договоров, производство).

· Результаты пакетов работ должны быть уникальными.

· Выполнение отчетов должно быть оформлено как выполнение отдельных пакетов работ.

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

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

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

Сложности, связанные с разработкой СДР:

Нахождение баланса между детализацией проекта и требованиями к сбору фактической информации и отчетности (излишняя детализация).

Разработка элементов СДР

без учета промежуточных результатов проекта (недостаточная детализация)

Недостаточное внимание к разработке СДР и переход непосредственно к формированию сетевого графика

Определение необходимости в дальнейшей детализации

В учебно-справочной литературе по управлению проектами для проектов средней сложности рекомендуется использовать до 6 уровней СДР: 3 верхних уровня для предоставления информации уровня заказчика, 3 нижних уровня для детализации информации уровня исполнителя. Глубина детализации СДР зависит от размера и сложности проекта, поскольку должна обеспечивать четкую формализацию целей и результатов работы, которые необходимо выполнить. Каждый пакет работ включает весь объем работ, выполняемый основной организацией, ответственной за данный пакет работ, так же, как и организациями, с которыми заключены подрядные договора.

Дальнейшая детализация необходима , если:

· Необходимо повысить точность оценки стоимости и длительности работ;

· Для пакета работ определен более чем один ответственный;

Объем работ, выполняемый в рамках данного пакета, описывает больше одного результата проекта; Необходимо раздельно определить стоимость процессов или результатов, описанных в данном пакете работ; Есть зависимость между работами внутри разных пакетов; Есть существенные перерывы в выполнении работ в рамках пакета; Меняются требования к ресурсам в течение времени в рамках пакета работ; Различаются исходные условия для работ внутри пакета работ; Существуют риски, связанные с частью пакета работ; Для части пакета работ может отдельно пересчитываться расписание.

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

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

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

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

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

Подобные иерархические деревья для приложений можно строить с целью:

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

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

· при создании чеклистов или тест-кейсов

· при выполнении тестирования исследовательским способом

· при проведении тестирования требований

· при планировании и оценке задач по тестированию

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

Признаки декомпозиции

Для разделения одного и того же приложения на подсистемы могут использоваться разные признаки декомпозиции. В качестве задачи на декомпозицию мы будем рассматривать приложение «Браузер» (см. рис. 1). Следует учесть, что во всех примерах, которые будут приведены ниже, декомпозиция не полная. Показаны лишь некоторые из подсистем первого и второго уровней.

Рис. 1. Скриншот приложения «Браузер»

В качестве признака разделения приложения могут использоваться:

внешний интерфейс (экран, окно, закладка и т.п. со всеми элементами интерфейса). На рис. 2 показан пример декомпозиции по этому признаку.
компонентная структура (функциональные модули приложения и их интеграция в более сложные модули). См. пример на рис. 3.
функции приложения и их варианты использования (см. пример на рис. 4),
обрабатываемые приложением объекты и данные (и часто нужно анализировать не то, что видно, а то что скрыто внутри — что передается на вход, что на выходе, что храниться внутри системы),
характеристики (параметры) объектов и данных или в целом всей системы (например, если объект — это файл, то параметры это — формат, размер, создатель, дата создания и т.д.),
действия над объектами (если объект «файл», то действия — удалить, переименовать, переместить, а если объект «список файлов», то действия — сортировать, фильтровать, выделить несколько файлов)
состояния, в которые переходит приложение или его модули,
этапы взаимодействия пользователя с приложением (см. пример на рис. 5),
виды пользователей,
характеристики качества (функциональность, удобство использования, производительность и т.д.),
и другие.

Рис. 2. Пример декомпозиции по элементам интерфейса приложения «Браузер»

Рис. 3. Пример компонентной декомпозиции приложения «Браузер»

Рис. 4. Пример функциональной декомпозиции приложения «Браузер»

Рис. 5. Пример декомпозиции по этапам взаимодействия пользователя с приложением «Браузер»

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

Принципы декомпозиции

1. Каждое разделение образует свой уровень.

Исходная система располагается на нулевом уровне. После её разделения получаются подсистемы первого уровня. Разделение этих подсистем или некоторых из них приводит к появлению подсистем второго уровня и т.д.

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

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

3. Вычленяемые подсистемы в сумме должны составлять всю систему (как пазл соединяться в одну картинку). При этом они должны взаимно исключать друг друга.

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

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

К неоднозначности может привести использование на одном уровне взаимно пересекающихся подсистем. Например, в сводке расходов за месяц, в большинстве случаев немного странно будут выглядеть пункты: еда, аренда помещения, канцелярия, коммунальные услуги, подогрев воды. Обычно подогрев воды относится к коммунальным услугам.Соответственно, при выделении этих пунктов на один уровень могут возникнуть вопросы формата: расходы на подогрев воды — это дополнительные расходы сверх нормы? Или это постоянные ежемесячные расходы? А не платим ли мы дважды за подогрев воды?

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

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

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

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

Системы нижнего уровня называются элементарными.

Если иерархическая схема используется как чеклист, то элементарные системы — это и есть идеи тестов.

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

5. Проводите критическую оценку декомпозиции каждого из построенных уровней и системы в целом.

Всё ли охвачено? Не пропущено ли? Может быть есть избыточные ветви или пересекающиеся?

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

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

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

Вспомните, что SADT-аналитик делает набросок декомпозиция, подвергает его критической оценке, перечерчивает и затем выпускает соответствующую папку. Эта глава состоит из трех уроков, связанных с созданием декомпозиции первого уровня - т.е. декомпозиции блоков диаграммы АО. В уроке 8 создается диаграмма, декомпозирующая один блок диаграммы АО. Урок 9 - авторская критика и пересмотр диаграммы. В уроке 10 рассматривается процесс создания папки для рецензирования.

Выполните все три урока без перерыва. Это даст вам точное представление об объеме работы, необходимой для декомпозиции ограниченного объекта. (Сравните усилия, потребовавшиеся для начала работы над моделью, с усилиями, потребовавшимися для декомпозиции одного блока.) Отведите около получаса на каждый урок, но не беспокойтесь, если затратите времени больше. Закончите работу, связанную с выполнением этих уроков, даже если вы испытываете трудности в следовании точному описанию системы на диаграмме АО.

Урок 8. Групповое построение диаграмм

Цель

Выбрать и декомпозировать один из блоков диаграммы АО.

Действия

Выберите блок диаграммы АО. Этот блок является контекстным на протяжении всего этого урока. Не выходите за его границы.

Мысленно проверьте этапы построения диаграммы: составить список объектов, составить список функций, сгруппировать функции в 3-6 блоков, начертить блоки в порядке убывания доминантности; начертить внешние дуги, начертить дуги управления, начертить входные и выходные дуги.

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

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

При вычерчивании делайте для себя примечания и определяйте терминологию.

После окончания работы проверьте ICOM-коды. Удостоверьтесь, что вы не забыли использовать граничные данные.

Примечания

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

На данном этапе не беспокойтесь о корректности этой диаграммы. Декомпозиции данного уровня редко удаются с первого раза.

Образец

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

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

Урок 9. Критическая оценка декомпозиции первого уровня

Цель

Критически исследовать построенную в уроке 8 диаграмму, чтобы определить, как она детализирует родительский блок диаграммы АО.

Действия

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

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

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

Примечания

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

Образец

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

Блок составить список покупок сделан более общим.

Это означает, и что теперь функция Спланировать покупки управляет еще и выбором магазинов.

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

Урок 10. Подготовка папки

Цель

Собрать в SADT-папке проверенную вами диаграмму первого уровня и связанный с ней глоссарий.

Действия

Подготовьте как вашу диаграмму, так и глоссарий и проверьте согласованность информации.

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

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

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

Примечания

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

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

Образец

В помещенном на титульном листе примечании содержится просьба к читателям определить термин информация о реальном количестве продуктов. Обратите внимание, как это затруднение отмечено в глоссарии.

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

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

1.2. Перечень предназначен для систематизации технологических процессов ФНС России и кодирования информации о них, а также для указания начальников структурных подразделений центрального аппарата ФНС России, ответственных за получение результата по технологическому процессу ФНС России, методологическое и/или организационное сопровождение его выполнения (далее - владелец технологического процесса ФНС России).

1.3. Также в Перечне при необходимости указывается начальник структурного подразделения центрального аппарата ФНС России, ответственный за получение результата по отдельным составным частям технологического процесса (далее - операции) и методологическое сопровождение их выполнения (далее - совладелец технологического процесса ФНС России).

1.4. Целью формирования Перечня является определение всех технологических процессов ФНС России и их владельцев (совладельцев) для обеспечения эффективной взаимосвязи и взаимодействия организационных, технологических, информационных и других ресурсов в рамках комплексного подхода к осуществлению деятельности ФНС России.

1.5. Систематизация технологических процессов ФНС России в Перечне основана на иерархическом методе классификации и последовательном методе кодирования.

1.6. Принципом систематизации является группировка технологических процессов ФНС России, выполняемых в рамках реализации функции/услуги/полномочия. При этом первоначальным является разделение всей совокупности технологических процессов ФНС России на основные технологические процессы ФНС России, а также вспомогательные и управленческие технологические процессы ФНС России.

1.7. Актуальный Перечень доступен для просмотра по ссылке, размещенной на Интранет-портале ФНС России.

1.8. Декомпозиция технологических процессов ФНС России для формирования Перечня осуществляется до уровня, при котором результатом выполнения является ценность в виде оформленного решения (документа) лица, уполномоченного на его принятие (утверждение, подпись) в соответствии с документом (нормативным правовым актом и/или приказами, планами, письмами, разъяснениями, методическими рекомендациями и т.п., а также поручениями руководства ФНС России и других ведомств), регламентирующим выполнение технологического процесса ФНС России.

1.9. Декомпозицией 1-го уровня является классификация технологических процессов ФНС России на:

Технологические процессы ФНС России, выполняемые непосредственно в целях реализации полномочий в сфере налогообложения, государственных функций, государственных услуг, а также информационного взаимодействия в соответствии с заключенными соглашениями, положениями и протоколами (далее - основные технологические процессы ФНС России);

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

урок 8. Групповое построение диаграмм

Цель

Выбрать и декомпозировать один из блоков диаграммы АО.

Действия

1. Выберите блок диаграммы АО. Этот блок является контекстным на протяжении всего этого урока. Не выходите за его границы.

2. Мысленно проверьте этапы построения диаграммы: составить список объектов, составить список функций, сгруппировать функции в 3-6 блоков, начертить блоки в порядке убывания доминантности; начертить внешние дуги, начертить дуги управления, начертить входные и выходные дуги.

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

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

5. При вычерчивании делайте для себя примечания и определяйте терминологию.

6. После окончания работы проверьте ICOM-коды. Удостоверьтесь, что вы не забыли использовать граничные данные.

Примечания

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

2. На данном этапе не беспокойтесь о корректности этой диаграммы. Декомпозиции данного уровня редко удаются с первого раза.

Образец

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

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

урок 9. Критическая оценка декомпозиции первого уровня

Цель

Действия

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

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

4. Постройте видоизмененную в соответствии с вашими замечаниями диаграмму и перечертите, если необходимо, диаграмму АО. Не забывайте проверять ICOM-связи между рассматриваемой диаграммой и диаграммой АО.

Примечания

Образец

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

2. Блок составить список покупок сделан более общим.

Это означает, и что теперь функция Спланировать покупки управляет еще и выбором магазинов.

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

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

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

урок 10. Подготовка папки

Цель

Собрать в SADT-папке проверенную вами диаграмму первого уровня и связанный с ней глоссарий.

Действия

1. Подготовьте как вашу диаграмму, так и глоссарий и проверьте согласованность информации.

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

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

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

Примечания

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

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

Образец

1. В помещенном на титульном листе примечании содержится просьба к читателям определить термин информация о реальном количестве продуктов. Обратите внимание, как это затруднение отмечено в глоссарии.

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