Analyze IT #2Электронный журнал для IT аналитиков Март 2009

Написать нам Подписаться на журнал

Наша командаСодержание выпуска

Планирование требований

Дополнительные материалы

Создание эффективной документацииАвтор: Нужненко С.

Другой треугольник разработкиАвтор: Байкин А.

Создание плана управления требованиямиАвтор: Zielczynski Р.Перевод: Мартыненко А..

Планирование требований. Этап, который забывают...Автор: Григораш В.

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

А знаете ли вы, что...Новости, анонсы событий из мира аналитики

Семинар “Планирование

требований”

Материалы и отзывы

А. Новичков Использование Method Composerпри описании сложных и нестан-дартных процессов. Практика применения

А. Байкин Как бороться с Изменениями

Требований?!

Над выпуском работали

Виталий Григораш

Старший бизнес-аналитикEPAM Systems, Санкт-Петербург

Анастасия Мартыненко

Бизнес-аналитикEPAM Systems, Самара

Александр Юняев

Бизнес-аналитикEPAM Systems, Рязань

Вводное слово- Он забирается на самую высокую сосну и оттуда планирует

- Простите, что планирует?

из спектакля «День Радио»

Дорогие Друзья!Жизнь не стоит на месте, и мы стараемся не стоять вместе с ней. Работа над журналом Analyze IT продолжается, - наша командаподготовила для вас очередной его выпуск, который, как мы надеемся, поможет Вам и сделает вашу работу интереснее. Журналприобрёл определённую структуру. Теперь на его страницах вы сможете найти не только познавательные статьи, но и последниеновости, анонсы событий из мира аналитики, смешные истории, анекдоты, карикатуры, и курьезы из жизни и работы. Все мы когда-нибудь задумывались о роли планов в своей жизни, и системности вообще. Изначально, давным-давно, еще в дет-стве мы жили бессистемно, просто жили, и радовалась или огорчалась, происходящим вокруг событиям. С нами приключалисьразличные истории, но мы никуда не спешили, у нас были желания и мечты, но их реализация зависела скорее от других, напри-мер, от родителей. Становясь старше и вступая на интересную тропу взрослой жизни, приходит понимание, что сложно жить какраньше. Появляются новые потребности, требующие реализации, а с ними появляются и цели...

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

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

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

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

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

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

А напоследок, несколько забавных фотографий и замечательный рассказ Григория Печенкина о борьбе двух кланов, наде-емся, заставят Вас улыбнуться :). Добро пожаловать в мир планирования требований!

С уважением, команда Analyze IT

Март 2009

Алексей Шемис

Системный аналитикАНТ-Информ, Санкт-Петербург

Analyze IT

Analyze IT

31 марта 2009 года выходит версия 2.0 BABOK®

IIBA (Международный институт бизнес-анализа) анонсировал на 31 марта 2009 года выход версии2.0 BABOK® (Свода знаний по бизнес-анализу). BABOK® представляет собой собрание знаний вобласти бизнес-анализа и содержит описание современных общепринятых практик.Предшествующая официальная версия 1.6 была выпущена в июне 2006 года. На протяжении двух споловиной лет создатели BABOK® получали огромное количество отзывов. На основе полученнойинформации Свод знаний был существенно дополнен и переработан.Как заявляют создатели BABOK®, целью выпуска новой версии послужило желание удостовериться,что Свод знаний достаточно адаптирован для удовлетворения потребностей сообщества бизнес-ана-литиков, а также стал легче для понимания и использования.Подробнее...

Страница 3

MacA&D Automated Requirements Management and Software Modeling Tool

4 марта 2009 года компания Excel Software заявила о выходе программного продукта MacA&D 3.0для компьютеров на платформе MAC OS.По заявлениям производителя данный продукт предназначен для системных аналитиков, проекти-ровщиков и программистов, и может быть использован для моделирования, управления требова-ниями, проектирования и многого другого. Подробнее...

SQA Days 2009. 5-я Международная конференция

23-24 апреля 2009г. в Санкт-Петербурге пройдёт ЮБИЛЕЙНАЯ 5-я Международная конференцияспециалистов в области обеспечения качества ПО, на которую приглашаются специалисты по тести-рованию и обеспечению качества программных систем, разработчики, аналитики и архитекторы си-стем, технические писатели, руководители среднего и высшего звена, а также другиезаинтересованные лица. Организатором конференции SQA Days уже по сложившейся традиции выступает компания SQALab(г. Москва) на базе портала IT-CONF.RU (ресурса, объединяющего высококачественные конференциидля ИТ-специалистов на пространстве СНГ, а также стран ближайшего зарубежья) совместно в пор-талом Software-Testing.Ru. Весенняя SQA Days-2009 будет посвящена вопросам, связанным с тестированием и обеспечениемкачества программного обеспечения: функциональному тестированию, интеграционному тестирова-нию, тестированию производительности, автоматизации тестирования и инструментальным сред-ствам, конфигурационному тестированию, тестированию удобства использования (usability) изащищенности, статическим методам обеспечения качества, а также вопросам внедрения процессовтестирования на предприятии, управления процессами обеспечения качества ПО, вопросам менедж-мента команд тестировщиков и инженеров качества ПО и другим сферам интересов QA-специали-стов. Читать далее...

А знаете ли вы, что ...

Software Engineering Forum

18-22 мая 2009г. в Минске пройдёт Форум по инженерии программного обеспечения Software Engi-neering Forum - SEF-2009. Software Engineering Forum-2009 – это первый в своем роде Форум, который объединит на одной пло-щадке популярные IT-ресурсы рунета и байнета, а также профессиональные IT-сообщества странСНГ и Балтии. Форум включает в себя весь спектр основных вопросов создания ПО, конкретизирует применениеязыков программирования, рассматривает успешные архитектурные решения и рекомендации, ка-сающиеся наиболее востребованных технологий, продуктов известных вендоров, а также OpenSource решений. Читать далее...

Analyze IT

Планирование требований. Этап, который забывают...

“Логика - начало мудрости. Аналогично, планирование - начало выполнения”Дж. Ханк Рейнвотер

“Как пасти котов”

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

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

Так же можно сказать и про работу с требованиями – чем тщательнеемы планируем работу аналитика, тем выше вероятность получения наи-лучшего результата.

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

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

Планировать или не планировать?В большинстве случаев этап планирования требований пропускают. Главная причина в основном одна – отсутствиевремени: «У нас нет времени заниматься бесполезной работой. Надо быстрее приступать к выявлению требований...У меня уже назначено интервью с представителем заказчика...». Максимум, что многие из нас делают, это подготав-ливают шаблоны документов требований, будь то спецификация требований или техническое задание, и составляюткалендарный план работ аналитической команды. А задумывались ли Вы над следующими вопросами:

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

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

• Достаточно ли детально будут описаны требования, для того чтобы отдавать их в разработку?• Каким образом команда тестировщиков будет выполнять проверку функциональности системы на основе тре-

бований?• Разделяете ли Вы уровни абстракции требований и типы требований?• Подготовились ли Вы к тому, что требования могут изменяться? Как Вы будете контролировать изменения

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

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

Страница 4

Статьи

Автор: Виталий Григораш

Analyze IT Страница 5

Планирование требований. Этап, который забывают...Автор: Виталий Григораш

Статьи

Если Вы скажете: «Никакого планирования нам не нужно, мы и так никогда не выходим за рамки бюджета и всепроекты сдаем в срок, и программисты всегда довольны нашими спецификациями и не задают никаких вопросов»,тогда мы ждем Вас на сайте http:\\www.uml2.ru, чтобы Вы поделились с нами своим опытом.

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

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

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

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

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

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

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

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

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

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

Бывают случаи, когда Заказчик предъявляет жесткиеограничения к оформлению технической документации,например, в соответствии с ГОСТ 34, в то время каккоманда разработчиков уже несколько лет работает, ис-пользуя Аgile методологию или какую-то другую. В такомслучае можно использовать два различных документа:

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

Analyze IT Страница 6

Планирование требований. Этап, который забывают...Автор: Виталий Григораш

Статьи

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

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

Описание процессов может быть реализовано в виде текстового пояснения, в виде диаграмм, моделей и др. Су-ществуют специальные средства для документирования процесса. Я как-то описывал аналитический процесс с по-мощью IBM Rational Method Composer, на выходе получается «кликабельная» html-страничка, что существенноупрощает изучение описанного процесса проектной командой.

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

В описании процесса рекомендуется придерживаться основных этапов при работе с требованиями:• Выявление требований.• Анализ требований.• Документирование требований.• Проверка (рецензирование) требований.• Управление изменениями требований.Для каждого этапа необходимо определить действия, которые должен выполнить аналитик для получения же-

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

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

• эксперт предметной области, который проверяет требования на соответ-ствие предметной области;

• бизнес-аналитик, который описывает бизнес-процессы Заказчика и подго-тавливает модели бизнес процессов, бизнес-требования и бизнес-правила;

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

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

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

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

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

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

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

Analyze IT Страница 7

Планирование требований. Этап, который забывают...Автор: Виталий Григораш

Статьи

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

Рассмотрим несколько примеров: • Человек имеет большой опыт работы с предметной областью и пришел в аналитики со стороны пользователя

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

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

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

• Человек с хорошими коммуникативными навыками и умением выслушать и грамотно изложить свои мысли –незаменим при работе с заказчиком.

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

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

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

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

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

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

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

работка требований к программному обеспечению».

Analyze IT Страница 8

Планирование требований. Этап, который забывают...Автор: Виталий Григораш

Статьи

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

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

В плане управления требованиями определяют следующие основные составляющие:• Типы требований (бизнес-требования, варианты использования, функциональные требования, нефункцио-

нальные требования и т.п). • Трассировка требований (проставляются связь «трассировки» между заданными типами требований). • Атрибуты требований (статус, приоритет, планируемая дата поставки и т.п).• Используемые инструменты (система управления требованиями, средства моделирования, средства комму-

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

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

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

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

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

почитаю описывать в плане все регламенты и аналитические процессы, что делает план законченным с точки зренияэтапа планирования требований. Шаблон плана управления требованиями можно найти в RUP. Со своей сторонымогу посоветовать Вам начать с малого и постепенно расширять содержание плана по мере улучшения процессови «созревания» проектной команды.

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

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

Если наложить шаблон документа на типы требований, то в первых разделахможно, например, описать бизнес-требования и основные «фичи» системы (англ. fea-tures - особенность, характерная черта), далее описать варианты использования, ука-зав трассировку на «фичи», а на основе сценариев вариантов использования описатьдетальные требования к системе. Наилучший вариант, когда требования различногоуровня абстракции (бизнес-требования, пользовательские требования, системные тре-бования) записываются в отдельные документы.

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

Analyze IT Страница 9

Планирование требований. Этап, который забывают...Автор: Виталий Григораш

Статьи

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

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

• Результаты планирования не должны оставаться на бумаге, они должны использоваться. Если все,что вы описали не используется, лучше вычеркните это из плана управления требованиями или разберитесьпочему оно не работает. Может быть нужно оптимизировать процесс или быть немного строже с подчиненнымив части выполнения регламентов? Если процесс работает отлично можно кричать «Эврика!!!», взять отпускна неделю и поехать отдохнуть. Теперь можно.

• Оптимизируйте и улучшайте процессы. В ходе работы иногда, выявляются недостатки первоначальногопланирования. И это нормально. Невозможно заранее все предусмотреть. Однако при оптимизации процессовстарайтесь искоренить только слабые места, не нужно кардинально менять принципы работы команды ана-литиков. Люди есть люди, они могут взбунтовать, особенно, если в результате улучшения часть работы при-дется переделывать. Продолжительность итерации, после которой необходимо оптимизировать процессы,зависит от каждого конкретного проекта и общих сроков на его реализацию. Рекомендую просматривать про-цессы на улучшение каждые 1-2 месяца.

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

• Обязательно присваивайте всем требованиям и другим артефактом уникальные идентификаторы. Этопозволит точно определять требования и планировать по ним работы. На текущем проекте мы работаем сбольшим количеством требований разных типов, и не имеем в распоряжении системы управления требова-ниями, поэтому идентификаторы присваиваем вручную по следующему принципу. Все артефакты разделенына функциональные области, каждая функциональная область имеет свой двузначный номер (XX). Каждыйтип артефакта имеет свое название, например, UC – вариант использования, RQ – требование, E – сущность,M – сообщение. Далее при создании артефакта аналитик, ответственный за функциональную область, при-сваивает артефакту составной уникальный в рамках системы идентификатор UC.XX.YY, E.XX.YY, где YY –уникальный номер данного типа артефакта в функциональном модуле XX.

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

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

Виталий ГригорашСтарший бизнес аналитик Санкт-Петербургского офиса компании EPAM Systems. Организатор и до-кладчик семинаров для системных и бизнес-аналитиков. Идеолог журнала Analyze IT.

Об авторе

Analyze IT

Создание плана управления требованиями

Примечание переводчика - Данная статья представляет собой адап-

тированный перевод небольшой части из книги P.Zielczynski “Require-

ments Management Using IBM® Rational® RequisitePro®”Из оригинального текста исходного материала при переводе были

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

мента IBM Rational RequisitePro .

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

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

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

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

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

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

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

• Сценарии: сценарии используются для описания последовательности действий при выполнении варианта ис-пользования. Это очень полезный тип требований. Они облегчают переход от вариантами использования ксценариям тестирования. В процессе моделирования и анализа мы разрабатываем диаграммы последова-тельности именно на основе сценариев, а не целых вариантов использования. Обычно мы компонуем не целыйВИ на каждой итерации, а набор сценариев из множества ВИ, постепенно «наращивая мясо» на каждый ВИк концу разработки. Как правило, мы начинаем со сценария, содержащего основной поток событий, впослед-ствии добавляя сценарии с альтернативными потоками.

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

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

Страница 10

Автор: Peter Zielczynski Перевод: Анастасия Мартыненко

Статьи

Analyze IT Страница 11

Создание плана управления требованиямиАвтор: Peter Zielczynski Перевод: Анастасия Мартыненко

Статьи

Примечание – действительно, сейчас редко можно встретить проект автоматизации бизнес-процессов «с

нуля». Как правило, производится замена или модернизация существующих систем. В этом случае «проблемы»

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

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

решает какую-то, возможно мелкую, проблему, заявленную на начальном этапе проекта, заказчик может быть

разочарован.

Каковы атрибуты этих требований?Атрибуты требований играют важную роль в управлении проектом. В некоторых случаях они могут помочь лучшепонять цели проекта.

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

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

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

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

Будем ли мы следовать методологии RUP в процессе разработки или воспользуемся какой-то другой мето-дологией?RUP(Rational Unified Process) это методология итеративной разработки ПО, которая становится все более и болеепопулярной. Преимущества использования RUP:

• Итеративный подход выявляет все риски на более ранних этапах• Доступность стандартных шаблонов документов

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

Analyze IT Страница 12

Создание плана управления требованиямиАвтор: Peter Zielczynski Перевод: Анастасия Мартыненко

Статьи

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

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

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

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

• Типы документов, в которых будут описываться требования.• Типы требований, которые будут описаны в каждом документе. • Атрибуты каждого типа требований.• Значения, доступны для каждого атрибута и их смысл.

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

Примечание – конечно структура полноценного плана управления требованиями для большого проекта может

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

ного проекта – ожиданиями заказчика, привычками проектной команды и т.д. Но в этом отрывке описаны во-

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

также принесет ощутимую пользу проекту :)

Анастасия МартыненкоБизнес аналитик Самарского офиса компании EPAM Systems.

О переводчике

Analyze IT

Другой треугольник разработки

Вот шел, говорил с Гришей, после семинара в Люксофте (Новое веб средство автоматизированного тестирования)и в голову пришла следующая идея о трех китах программирования...

Всем знаком главный треугольник разработки (Рис.1):

Рис.1

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

* Требования* Разработка* Тестирование

Как правило мы заостряем наше внимание на процессе разработки, тем самым зарывая проект, и называя раз-работку как бы Agile (Рис. 2 A). А что если перевернуть этот треугольник и уделять больше внимания требованиями тестированию (Рис. 2 B):

Рис. 2 A Рис. 2 B

Вот так :) Данные мысли относятся к разработке 80% программ - самых обычных программ. В остальных 20%(супер нагруженных, умных и т.д.) должно уделяться больше внимания и реализации и архитектуре, но это уже со-всем другая история и деньги ...

Страница 13

Автор: Александр Байкин

Александр БайкинВедущий аналитик и консультант по процессам разработки ПО компании Автомир. Основатель иидеолог ресурса uml2.ru. Тренер и консультант в области ИТ анализа и методологий разработкиПО. Докладчик многих конференций и семинаров.

Об авторе

Статьи

Analyze IT

Создание эффективной документации

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

Чуть позже, а именно 28 июля 2008г. я принял участие в тренинговом марафоне Traininglabs 2008 с тренингомна тему "Создание эффективной инженерной документации". В разминке тренинга была деловая игра, основой ко-торой стало сравнение трех видов представления информации, из статьи, описанной выше. К моему стыду подго-товленный материал немножко не удалось уместить в 1.5 часа тренинга и в конце я пообещал участникам написатьстатью по материалам тренинга, чтобы восполнить пробел для всех заинтересованных хотя бы в теоретическойчасти.

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

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

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

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

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

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

Страница 14

Автор: Сергей Нужненко

Статьи

ВведениеКому это нужноЧто это такоеТеория

Что такое документИнженерный документСистема документированияПроцессный подходНазначение и область применения документаКонтекст документа и источники информацииКонцепция трассировки и информационная схема документаИнформационная схема документаСпособы представления информацииШаблон документаПринципы оформленияРазумная бюрократия: принципы согласования документовВиды решений, подлежащие документированию в ИТ проекте

Технология создания системы документированияЗаключениеP.S.

Analyze IT Страница 15

Создание эффективной документацииАвтор: Сергей Нужненко

Статьи

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

При отказе от документации к концу 5-го или 6-го месяца разработки можно обнаружить, что проект уже вышелза сроки на 50% и назвать точную дату его завершения не представляется возможным, так как мы не до конца пред-ставляем себе требования, архитектура внутренне противоречива, а количество и качество дефектов не поддаетсяконтролю. Разработчики утверждают, что заказчик уже 4-й раз меняет свои решения, при том, что где-то со второгоили третьего раза разработка ходит по кругу.

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

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

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

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

Почему же нам не всегда подходят имеющиеся шаблоны? Ответ прост: достаточно давно было замечено, чтововлеченность в построение нового порядка облегчает участникам принятие этого порядка. Чужие шаблоны не оп-тимизированы под требуемые процессы, часто там не учтены некоторые тонкости и детали, туда не включены раз-делы, требуемые в данном случае, в другие же нечего писать. Но еще чаще шаблоны чудовищно избыточны,разработаны под ситуацию с минимальным совмещением проектных ролей, и, следовательно, не годятся для ма-леньких проектов, в которых потеря одной-трех человеко-недель только на обкатку чужих шаблонов составляет не1-2% общей плановой трудоемкости, а все 10-15%, превращаясь в существенный фактор риска нарушения срокови бюджета, не говоря уже об издержках, вызванных частью документов, ненужных в данном случае.

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

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

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

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

чень шагов с описанием действий по ее построению.

Analyze IT Страница 16

Создание эффективной документацииАвтор: Сергей Нужненко

Статьи

ТеорияЧто такое документСуществует множество определений документа. Приведем краткие выжимки из словарных статей, содержащие важ-ные для нас факты:

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

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

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

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

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

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

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

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

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

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

Большой юридический словарь Зафиксированная на материальном носителе информация с рекви-зитами, позволяющими ее идентифицировать

Информатика. Энциклопедический систе-матизированный словарь-справочник

Материальный носитель информации, зафиксированной вне па-мяти человека

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

Analyze IT Страница 17

Создание эффективной документацииАвтор: Сергей Нужненко

Статьи

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

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

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

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

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

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

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

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

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

Analyze IT Страница 18

Создание эффективной документацииАвтор: Сергей Нужненко

Статьи

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

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

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

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

Протокол совещания больше работает после совещания, напоминая участникам решения и принятые обяза-тельства.

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

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

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

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

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

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

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

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

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

Analyze IT Страница 19

Создание эффективной документацииАвтор: Сергей Нужненко

Статьи

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

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

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

Analyze IT Страница 20

Создание эффективной документацииАвтор: Сергей Нужненко

Статьи

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

Части протокола связаны между собой и с другими документами. Так, ФИО участников и в списке рассылки обя-зательно будут содержаться в перечне проектной группы, название проекта точно указано в приказе о старте проекта,а решения должны быть привязаны к вопросам повестки.

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

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

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

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

Текст Таблица ДиаграммаОписательная способность + +- -Однозначность + +- -Минимальная избыточность - +- +Наглядность - +- +Минимальное нарушение целостности - +- +Скорость поиска фактов - +- +-Анализ сложных связей - - +минимальный объем контекста + +- -Минимальное замедление работы с документом при росте объема - + +-Возможности машинной обработки - + +-Чтение без подготовки + + -

Analyze IT Страница 21

Создание эффективной документацииАвтор: Сергей Нужненко

Статьи

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

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

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

Чем полезен шаблон? Шаблон позволяет ничего не забыть при составлении документа. Как говорят: "рыба до-кумента задает вопросы.", а нам остается только собрать информацию для ответа на них. Шаблон полезен как тем,что управляет процессом сбора информации и составления документа, так и тем, что мы не тратим время на пла-нирование документа заново.

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

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

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

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

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

решения; - шаблон документа должен упрощать его заполнение: содержать значимые имена разделов, по возможности

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

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

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

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

титулах (например, название);

Analyze IT Страница 22

Создание эффективной документацииАвтор: Сергей Нужненко

Статьи

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

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

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

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

так и колонок. Таблицы должны иметь номера и названия.

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

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

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

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

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

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

Analyze IT Страница 23

Создание эффективной документацииАвтор: Сергей Нужненко

Статьи

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

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

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

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

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

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

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

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

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

Следует понимать, что избыточность документирования - вещь субъективная. Для кого-то составление и рас-сылка неформального (без подписей) полустраничного протокола ежедневных совещаний занимает 5 минут в деньи не считается чем-то обременительным, для кого-то другого это кажется излишней бюрократией. Естественно, кто-то другой мог бы составлять эти протоколы, но он не вполне дружен с литературным языком, боится показать этоколлегам, испытывает что-то похожее на проектный паралич перед чистым листом бумаги и тратит на такой документвсе 30, а то и 60 минут.

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

Если говорить о времени, то приверженцами тайм-менеджмента (см здесь) доказано, что хронометраж (отчет-ность о выполнении деятельности) достижим с разрешением до 5 минут. Планы могут иметь деление на 15ти ми-нутные отрезки. Однако это крайности. В действительности вполне достаточно и целесообразно почасовоепланирование и отчетность, что вполне достижимо, малообременительно (в рабочем дне всего лишь 8 часов, в не-деле - 40) и применяется повсеместно в организациях, достигших определенного уровня зрелости.

Analyze IT Страница 24

Создание эффективной документацииАвтор: Сергей Нужненко

Статьи

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

Отсутствие четкой и детализированной документации часто означает отсутствие четких и детализированныхмыслей, что означает отсутствие конкретных и однозначных планов и решений. Однако документация в маленькомпроекте должна отличаться от документации в большом, так как она имеет меньший объем и служит для коммуни-кации меньшего количества людей. На чем же можно сэкономить? В маленьких проектах обычно разрабатываютсясистемы небольшого масштаба, которые не требуют для описания толстых пачек документации. Как следствие, мыможем уменьшить издержки на документирование, сэкономив на тех частях документов, которые служат оптимиза-ции поиска в больших пакетах документов. Кроме этого, разбиение пакета документации на отдельные документыдиктуется порядком разработки и согласования документов: различными составителями и разделением ответствен-ности за принятые решения. Малая численность команды, малая длительность проекта и конкретные особенностиситуации позволят вынести некоторые вопросы в контекст, в частности, пренебрегая обширным глоссарием.Еслиучесть, что разделы с назначением, областью применения, обзором, содержанием и списком ссылочных документовзанимают 2-3 страницы, а в маленьком проекте концепция, требования и архитектурные решения могут сами зани-мать в среднем по 3-10 страниц, мы можем сэкономить от 20 до 50% объема, объединив три документа в 1.

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

Малый объем требований и решений позволяет несколько снизить требования к систематизации, отменяя работупо разделению информации и раскладыванию по полочкам разных разделов обширного документа. Такое отсутствиесистематизации может оказать медвежью услугу, если выяснится, что мы учли не все, отказавшись от шаблона, не-избежно задающего все важные на данном этапе вопросы. В результате можно выдвинуть такую рекомендацию: от-сутствие систематизации в документе допустимо, если его объем мал и позволяет прочесть документ и построитьбыстро в голове (или на паре листиков бумаги) модель, позволяющую проверить информацию на полноту и непро-тиворечивость. Еще одним важным фактором, влияющим на документирование маленького проекта является ско-рость и объем поступления изменений в целях и требованиях. Чем чаще меняются требования, тем выше издержки(неподъемные для маленьких проектов) на переработку вторичных документов: системных требований, архитектур-ных документов и излишне детальных планов. Даже при теоретической неизменности бизнес-требований изменениямогут возникать из-за того, что сбор требований идет параллельно с разработкой, в результате чего список бизнес-требований непрерывно пополняется, вызывая изменения в архитектурных решениях.

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

Учитывая написанное выше, я составил следующий список вопросов, подлежащих документированию в малень-ком проекте с рекомендациями:

Цели: с точностью до показателей достижения и концептуальное описание результата;

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

Планы: ничто не мешает иметь маленький план маленького проекта на уровне договорных этаповили ключевых событий внутри этапа и быстроизменяемый список оперативных задач с по-часовым учетом времени;

Эксплуатационная документация: в полном объеме, необходимом потребителям;

Системные требования и архитектура: могут быть в виде черновых набросков для внутреннего использования или отсутствовать;

Обнаруженные дефекты и изменения (дополнения) бизнес-требований:

в полном объеме;

Значимые решения и результаты работ,утверждаемые заказчиком:

например, в виде протоколов.

Документ, управляющий тестированием: Как минимум в объеме, необходимом для формальной приемки.

Analyze IT Страница 25

Создание эффективной документацииАвтор: Сергей Нужненко

Статьи

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

тирования. В этом разделе дано краткое описание практических шагов по построению системы документированияили по созданию одного документа:

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

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

1. Определение структуры пакета до-кументов

1.1. Кратко описать цели проекта илирегулярной деятельности

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

1.2. Описать состав участников и рас-пределение ответственности,

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

1.3. Кратко описать процесс производ-ства работ.

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

1.4. Определить состав документов ивиды документируемых фактов ирешений

на основании составленного описания процесса производстваработ.

2. Для каждого документа

2.1. Описать назначение документов Которое мы определили в шагах 1.3 и 1.4.

2.2. Описать область применения доку-ментов

Которую мы определили в шагах 1.3 и 1.4.

2.3. Описать источники информации:документы - основания разработкии контекст

На основании схемы процесса производства работ.

2.4. Создать схему документа Пользуясь списком отвечаемых вопросов из шагов 1.4 и 2.1

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

2.6. Написать обзор документа на основании схемы и шаблона документа.

3. Дополнительно

3.1. Проанализировать трассировкимежду документами и частями до-кументов

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

3.2. Детально спланировать процессысбора информации-создания-согла-сования

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

3.3. Собрать информацию и оформитьдокумент,

корректируя схему документа и шаблон при необходимости.

Analyze IT

Создание эффективной документации

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

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

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

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

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

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

P.S.Тренинг, по мотивам которого написана статья, я проводил не в последний раз. Если будет угодно судьбе, то бли-жайшей осенью (2008г) я смогу провести его в расширенном формате при поддержке одной из фирм, продающейтренинги. Если есть заинтересованность, пишите, мы всегда сможем договориться :)

Страница 26

Автор: Сергей Нужненко

Сергей НужненкоБизнес-тренер, руководитель проектов и координатор программы внутренней информатизации ООО "ВНИИГАЗ". Внедавнем прошлом: руководитель проектов внедрения автоматизированных систем и консалтинговых проектов. На-работанный опыт и знания обобщен в виде статей и авторских тренингов по целеполаганию, анализу, моделирова-нию и проектированию бизнес и ИТ-систем, а так же по управлению проектами. Представленная статья впервыеопубликована на персональной страничке автора: http://boatmanshome.ru

Об авторе

Статьи

Analyze IT Страница 27

Спецификация и конечный продукт... Неучтенные требования...

Временная “заплатка”. Функциональность будет реа-лизована в следущем билде...

Руководство пользователя...

Картинки, которые напомнили нам нюансы аналитической работы

Аналитики шутят

Давно отгремели великие битвы ушедшей Эпохи Корпораций. Обратились в прах и развея-лись по ветру титанические Проекты прошлого. Забыты многие славные имена.Но предания о благородных и бесстрашных воинах древности остались в памяти клана.Боевые песни Хакеров продолжают будоражить кровь всё новых и новых поколений Ай-тишников. Их ветхие манускрипты по-прежнему служат неиссякаемым источником мудро-сти.Настоящий трактат представляет собой скромную попытку описать некоторые виды и обы-чаи представителей двух великих кланов, издревле враждующих меж собой.

КЛАН КОРПОРАЦИИАдминистратор

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

Чтобы эффективнее сражаться с Командой, Администраторы специализируются в разных видах вредительской дея-тельности. При этом они обожают выстраивать иерархические системы подчинения, в которых присваивают себеразличные звания с приставкой «менеджер». Так, менеджер по персоналу сторого следит за тем, чтобы все сотрудники соблюдали единый и максимально не-удобный «корпоративный стиль одежды», непременным атрибутом которого является галстук-удавка. Офис-менеджер обеспечивает наименее комфортные условия для работы Айтишников в одинаковых, выстроенныхпо линейке, камерах-кьюбиклах. А менеджер по снабжению позаботится о том, чтобы самое необходимое оборудование пришло в тот момент, когдаоно уже точно никому не нужно.

Администратор с МетрикойОбучите Администратора рассчитывать какой-нибудь формальный показатель, и вы удвоите его силу. Ведьтеперь он владеет научно обоснованным методом управления! Интеллектуальное превосходство Айтиш-ников больше не тяготит его самолюбие, а уверенность в собственной безоговорочной правоте придаётему ярость берсерка.

Собравшись вместе, Администраторы с Метриками становятся ещё более опасны. Совместными усилиями они соз-дают и совершенствуют Систему Показателей, с помощью которой наносят разрушительные удары по Команде сдальней дистанции, даже не покидая своих кабинетов.

Гуру МетодологииСообразительный и целеустремлённый Администратор, освоивший достаточное количество Метрик, можетсвести их в единую Методологию, и тем самым превратиться в Гуру. Гуру Методологии необычайно толстокож и обладает огромной разрушительной силой. Даже одиночномуГуру вполне под силу уничтожить средних размеров Проект. А поодиночке они ходят редко: обычно Гуру

сопровождает толпа восторженных Администраторов, которых он приобщает к Корпоративной Мудрости с помощьюспецифической магии.К счастью, Гуру встречаются не так уж часто, и ещё реже они сопровождают Проект от начала до конца. Услуги ГуруМетодологии баснословно дороги, и мало какой бюджет выдержит их постоянное присутствие.

Analyze IT

Битва за проект

Страница 28

Автор: Григорий Печенкин

Аналитики шутят

Analyze IT Страница 29

Битва за проектАвтор: Григорий Печенкин

Аналитики шутят

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

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

АкционерКак и Заказчики, Акционеры страдают раздвоением личности и чаще всего сами не знают, чего хотят. Чрез-вычайно опасны своей силой, свирепостью и непредсказуемостью. Собравшись в достаточном количестве,Акционеры могут полностью уничтожить Проект, воспользовавшись своей тёмной магией.

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

ОптимизацияПусть вас не обманывает благородное происхождение этого слова. Оно больше не имеет никакого отно-шения к компиляторам. Корпорация полностью извратила его смысл: теперь Оптимизацией называетсятупое сокращение расходов, и Акционеры коварно применяют это заклятие в самых неожиданным местах.Хакеры и Программисты могут пережить заклятие Оптимизации. Труднее приходится Аналитикам («Какая

ещё модель? Она у всех одинаковая!») Но чаще всего от Оптимизации страдают Тестировщики — как правило, онипервыми гибнут от этого заклятия («Что? Штатные тестировщики?! Пусть программисты программируют свои про-граммы без ошибок — и тогда никакое тестирование не понадобится!»).

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

года».

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

может быть потеряно в любой момент из-за своеволия и непокорности этих тупых Айтишников!Почти всё время Вице-Президенты тратят на то, чтобы создать у окружающих иллюзию собственной необходимостии незаменимости. Именно для этого они добавляют к своему титулу завораживающие слух слова из тайного языкамагических заклятий, который изучают в мрачных подземельях Школ Бизнес-Администрирования. Так появляютсяВице-Президенты по мерчендайзингу, по инвестициям, а также самый страшный тип: Вице-Президент по человече-ским ресурсам.

Превращение в ЗомбиНет более страшной судьбы для Айтишника, чем стать Офисным Зомби. Чёрная магия Вице-Президентапозволяет ему не просто уволить любого Айтишника, но превратить его в офисную нежить, пятую колоннуКорпорации, покорного раба — бездумного и бездушного, беспрекословного и тупого исполнителя приказов.Внезапное появление такого Зомби вносит смятение в Команду: ведь удар наносится оттуда, откуда его

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

Analyze IT Страница 30

Битва за проектАвтор: Григорий Печенкин

Аналитики шутят

КЛАН АЙТИШНИКОВАналитики

Тот, что слева, это Системный Аналитик. А справа — Бизнес-Аналитик. Или наоборот... На самомделе, их все путают. В общем, это тот странный народ, который не только знает, что такое UML, нои на полном серьёзе считает его языком. То есть они реально на нём разговаривают и искреннеудивляются, когда окружающие их не понимают.

Главное преимущество Аналитиков — в мастерском владении приёмами дальнего боя (по email и по телефону), начто Кодеры и Хакеры не способны в принципе. Пара-тройка Аналитиков вполне может завалить одиночного Заказ-чика до того, как он приблизится к ним на опасное расстояние.Следует помнить, что Аналитики больше других нуждаются в постоянном совершенствовании своих навыков и ору-жия. Они не защищены бронёй Кодеров, и магия Хакеров им неподвластна, поэтому в битве они могут полагатьсятолько на свой опыт и отточенные боевые инструменты.

ТестировщикиСуровые парни, одержимые страстью к разрушению. Девиз Тестировщиков: «что один человек построил,то другой завсегда сломать сумеет». Не боятся никаких преград, способны сломать всё, что угодно — дажескалы уступают их напору. Находиться рядом с ними бывает просто опасно. Достоверно известно, что Те-стировщиков побаиваются даже Хакеры, хотя они, конечно, не подают виду.

Несмотря на это, Тестировщики наиболее уязвимы перед кознями Корпорации. С точки зрения солдат Корпорации,непредсказуемые Тестировщики только подрывают их благополучие, в одно мгновение разрушая выстроенные имипланы, вместе с которыми легко взлетают на воздух надежды на премии и повышения за досрочное завершениеПроекта. Завидев Тестировщиков, вся орда Корпорации бросается в атаку. Но Тестировщики ещё и очень шустрыебойцы: один стремительный бросок — и ба-бах! — очередное хитроумное построение Корпорации дымом развея-лось по ветру. Фольклор тестировщиков обширен и своеобразен. Многие их притчи ошибочно принимаются за анек-доты. Например, тот парень, который один чугунный шар сломал, а другой потерял, на самом деле был гениальнымтестировщиком. Или попробуйте, расскажите тестировщику такой анекдот. «Готово, хоязин!» - «Что, уже сделал?» - «Ага, сломал!» Тестировщик только пожмёт плечами: что тут смешного? Человек успешно справился с заданием.

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

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

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

Право ВетоНаходящееся на зыбкой границе светлой и тёмной магий, заклинание Права Вето позволяет РуководителюПроекта тормозить особо ретивых представителей Корпорации, обращая против них взлелеянную ими жеБюрократическую Силу Инструкций. Особенно эффективно это заклинание против Бухгалтерского Десанта.«Переселить программистов в общий зал? Но это потребует времени! А согласно Положению о Проекте,

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

Вы что, идиоты?!!Хотя обычно Руководитель Проекта выглядит добродушным и рассудительным, лучше не пытаться довестиего до кипения. В гневе он может применить это разрушительное заклятие, и тогда несладко придётсявсем, кто оказался поблизости, не исключая и представителей Команды. Солдаты Корпорации при этомгибнут от недоумения, а воины Команды — от угрызений совести. Надо заметить, что самому Руководи-

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

Analyze IT Страница 31

Битва за проектАвтор: Григорий Печенкин

Аналитики шутят

СисадминГерой айтишного фольклора, неизменный персонаж былин и сказаний Башорга, Сисадмин занимает осо-бое место среди Айтишников. Говорят, что в каждом Сисадмине умер Кодер. Правда же состоит в том, чтосами Кодеры втайне завидуют свободе и независимости Сисадмина.Сисадмин не носит оружия и не принимает непосредственного участия в Битве. Но, поскольку ему открыты

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

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

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

ХакерХакеры составляют главную ударную силу Команды. Если в Проекте не осталось ни одного Хакера, битвапроиграна. У Проекта нет никаких шансов на успех.Мощь Хакера — в его магии. Магия Хакеров укрепляет и сплачивает Команду и приводит в трепет Корпо-рацию.

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

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

ИгнорВыглядит это так. К Хакеру, погруженному в медитацию, подкрадывается Вице-Президент — злораднооскалившись, предвкушая, как он наконец-то застукает этого выскочку и бездельника на месте преступле-ния, тут же, не сходя с места, уволит его, и может, даже сразу превратит в послушного Зомби! И тут Хакерподнимает свой ясный взор и, глядя сквозь Вице-Президента, хрустальным голосом спрашивает: «Кто

здесь?»И всё. Эти слова звенят погребальным колоколом для Вице-Президента. Ибо ему достаточно задуматься лишь намгновение над вопросом «Кто я? Зачем я здесь?», чтобы потерять сразу всё — и магию, и силу, и власть.Это заклинание действует только на клан офисной нежити, то есть может применяться исключительно против Вице-Президентов и Офисных Зомби, осознающих свою полную бесполезность для Проекта. На Администраторов, святоверующих в свою незаменимость, заклинание не действует. Пытаться их игнорировать — только зря тратить ману.

Григорий ПеченкинПо визитке - Технический директор российского филиала южнокорейской компании CyberNet.В реальной жизни - IT специалист широкого профиля: программист, аналитик, тестировщик, технический писатель,специалист техподдержки, в общем, менеджер проектов в маленькой компании.

Об авторе