КомпанияУслугиОбучениеСервисы

Подход к оценке сроков создания технической документации

Версия для печати

Подход к оценке сроков создания технической документации

Михаил Острогорский, «Философт»

Тезисы доклада на конференции «Документирование сегодня», 2008 г.

Почему важно уметь оценивать сроки

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

Общие соображения об оценке сроков документирования

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

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

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

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

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

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

Методики оценки сроков разработки технической документации существуют и даже описаны в стандартах. Так, ГОСТ Р ИСО/МЭК 15910-2002 предлагает целых два метода: нисходящего проектирования и поминутно-почасовой.

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

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

Метод, схожий с поминутно-почасовым, описан в пособии компании Sun «Read Me 1st».

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

Что с этим делают программисты

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

Так, в методе «Use-Case Points» метриками служат свойства прецедентов использования системы. Для каждого актора и каждого прецедента использования в зависимости от их сложности по определенной шкале начисляются баллы. Также для проекта рассчитываются коэффициент технической и коэффициент организационной сложности. Дальше по предусмотренной методом формуле на основе суммы баллов и этих двух коэффициентов получается мера сложности задачи в единицах, называемых UCP. Норматив пересчета UCP в человеко-часы, вообще говоря, для каждой фирмы свой (и устанавливается при внедрении метода), однако, считается, что при правильной организации работы он лежит в определенных границах.

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

Что с этим будем делать мы. Метрики документирования

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

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

В качестве задачи метрик будем использовать:

Метрики проекта

  • 1) объем доступной документации разработки в страницах;
  • 2) количество экспертов;
  • 3) количество рецензентов;

Метрики пользовательской перспективы

  • 4) количество функциональных ролей;
  • 5) количество пользовательских задач;
  • 6) количество функций программы;
  • 7) количество реакций пользователя на сообщения программы.

Метрики данных

  • 8) количество сущностей, с которыми работает программа;
  • 9) количество атрибутов объектов;
  • 10) количество поддерживаемых форматов данных.

Метрики интерфейса пользователя

  • 11) количество главных окон и рабочих областей;
  • 12) количество крупных экранных форм;
  • 13) количество команд главного меню;
  • 14) количество сообщений об ошибках.
Выделим следующие виды работ:

Изучение продукта

  • 1) чтение документации;
  • 2) интервью;
  • 3) работа на стенде.

Составление плана документирования

  • 4) анализ требований к документу;
  • 5) составление структуры документа;
  • 6) составление и согласование плана документирования.

Написание текста

  • 7) изложение структурной информации;
  • 8) изложение процедурной и функциональной информации;
  • 9) изложение справочной информации;
  • 10) подготовка рисунков.

Согласование текста

  • 11) получение и обсуждение замечаний;
  • 12) внесение исправлений.

Оформление текста

  • 13) авторская разметка;
  • 14) расстановка перекрестных ссылок;
  • 15) разметка указателя.

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

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

Трудоемкостьi = Метрика1*Ti1 + Метрика2*Ti2 +…+ МетрикаN*TiN.

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

Общая трудоемкость равна сумме (или в более гибком варианте метода взвешенной сумме) трудоемкостей по всем видам работ.

Планы развития метода

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

План работы по этому направлению:

  1. Обсуждение концепции проекта.
  2. Составление уточненных списков метрик и видов работ.
  3. Публикация опросных листов с двумя векторами: метрики и трудозатраты по видам работ.
  4. Заполнение участниками проекта опросных листов. На этом этапе каждый участник выбирает подходящую задачу из числа своих текущих задач. Значение метрик он вводит в опросный лист перед началом работы. Значения трудозатрат по видам работ участник получает путем хронометража и вводит в опросный лист в конце работы. Каждый участник отсылает свой опросный лист в оргкомитет проекта.
  5. Математическая обработка данных. Получение коэффициентов таблицы нормативов.
  6. Публикация полученной таблицы нормативов для использования всеми заинтересованными лицами.

Пример таблицы для расчета в формате Microsoft Excel.

Презентация в формате PowerPoint.

Предложения по проекту можно присылать автору по адресу misha@philosoft.ru.

© «Философт», 2008–2017

+7 (499) 500-44-77

mail@philosoft.ru

SpyLOG