Клиент Notal System - перехват событий в офисных программах

Постановка проблемы
Большинство документов СЭД (системы электронного документооборота) редактируются в офисных программах - нас интересуют ставшие стандартом де-факто Ms Office и Open Office. В них требуется научиться делать следующие вещи:

• Перехватывать закрытие документа
• Перехватывать печать документа
• Отличать документ, полученный из Notal System, от просто документа на локальном компе
• Различать взятые из Notal System документы по типу - взятые на просмотр и взятые на редактирование
• Различать, из какой именно базы Notal System взят документ - пользователь может с одного компа работать с несколькими базами

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

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

• Складывать взятые из СЭД файлы в определенную папку (или структуру папок)
• Записывать имя файла в БД на локальном компе и потом сверяться с этими записями
• Всю нужную информацию кодировать в имени файла

Поскольку СЭД Notal System работает в веб-интерфейсе, то не всё подконтрольно: разные браузеры складывают документы в разные папки, причем не всегда это можно настраивать. Кроме того, использовать локальную БД нежелательно, поскольку это переусложнит клиентскую часть и может потеряться гибкость веб-технологий.
Опознавать документ будем по имени файла, причем это опознание должно быть устойчиво к некоторым модификациям имени файла которые делают браузеры: к примеру, при повторном скачивании файла браузеры по-разному модифицируют его имя - Opera добавляет в конце " (1)", " (2)" и т.д., Mozilla Firefox добавляет "-1", "-2" и т.д.

Структура имени файла документа из Notal System
Различать разные базы Notal System будем по ключевому числу NN - целое трехзначное число, желательно простое или произведение двух двузначных простых чисел. Зададим его и тогда формат взятого из Notal System документа будет таким (жирным выделены константные части:

iiii_vvvE=AAAAAAABBB=

где iiii - id документа в Notal System (переменое число знаков, цифры, не может начинаться с 0),
vvv - номер версии документа (переменое число знаков, цифры, не может начинаться с 0),
E - указатель на то, что документ взят на редактирование; для взятых на просмотр ставим знак V,
AAAAAAA - случайное число 7 цифр с ведущими нулями, если требуется. Должно быть больше 1000.
BBB - проверочный код, 3 цифры с ведущими нулями, если требуется; вычисляется по формуле BBB = AAAAAAA mod NN, т.е. остаток от деления AAAAAAA на ключевое число NN.
Знаки "_" и "=" задают структуру имени файла. Всё, что идет после второго знака "=", при аналие отбрасывается.
Структура имени файла позволяет узнать id документа и узнать, взят ли документ на редактирование или только на просмотр. Номер версии документа для работы программы не важен, но полезен для пользователя. Случайное число в имени файла гарантирует, что дважды взяв документ из СЭД мы получим разные имена файлов. Проверка соотношения чисел AAAAAAA и BBB позволяет с большой долей надежности установить базу Notal System, из которой взят документ.

Расчет вероятности ложного опознания базы-источника документа
Считаем, что сама специфическая структура имени файла однозначно указывает на то, что файл взят из СЭД Notal System. Пусть на локальном компьютере пользователя зарегистрированы две базы с ключевыми числами NN₁ и NN₂. Тогда вероятность того, что одновременно выполняются два соотношения

• BBB = AAAAAAA mod NN₁
• BBB = AAAAAAA mod NN₂

равна 1/НОК(NN₁, NN₂), где НОК - наименьшее общее кратное. Поскольку мы выбираем NN₁ и NN₂ простыми, то формула упрощается до 1/(NN₁*NN₂). Поскольку оба числа трехзначные, то полученная вероятность гарантированно меньше 10^-4 и почти всегда меньше 10^-5, что позволяет нам не заботиться о ложных срабатываниях (по крайней мере в первой версии клиентской части Notal System).

Необходимые доработки серверной части Notal System

• Добавить в раздел общей информации системы ключевое число
• Создать механизм задания ключевого числа - вручную или случайно из списка подходящих простых чисел (контроль того, что все эти числа для установленных на нашем сервере баз различны, осуществляем пока вручную)
• Написать функцию API, которая запрашивает у базы ее ключевое число (понадобится для конфигурирования ini-файла клиента)

Информация в ini-файле на машине клиента
В файле notalconfig.ini, расположенном в папке C:\NotalSystem\conf\, раздел каждой базы (имя раздела [base*], где "*" означает любой текст без пробелов) должен содержать следующие строки:

URL = http://test.notalsystem.ru/ - веб-адрес базы Notal System
KeyNumber = 449 - ключевое число
Name = "Тест" - название базы: произвольный краткий текст, нужен для показа в диалоговых окнах и т.п.

Сейчас считаем, что пользователь руками редактирует ini-файл, позже можно сделать конфигуратор клиента.

Что должна делать клиентская программа в офисном пакете
Для каждого офисного пакета (и в будущем - для программ инженерной графики) настраиваем отдельно, но одинаковый функционал:

• Перехватываем закрытие документа и определяем базу
  • Если он взят на редактирование и изменен, то предлагаем отправить новую версию документа в СЭД
• Перехватываем печать документа и определяем базу
  • Если он взят на редактирование и изменен, то печатаем и после этого отправляем новую версию документа в СЭД. Вариант: спрашиваем пользователя, делать ли это, если нет, то не отправляем новую версию, но и не печатаем.
  • Если он взят на просмотр и изменен, то не печатаем. Вариант: предупреждаем об этом пользователя, проверяем, что он имеет право редактировать этот документ, предлагаем ему сохранить отредактированную версию в СЭД (тут используется механизм, который мы используем для добавления новых версий документов из 1С, т.е. не беря предварительно документ на редактрирование.
  • Если документ не был изменен, то печатаем без каких-либо иных действий.

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

Особенности реализации перехвата событий в Ms Office
Нас интересуют только Ms Word и Ms Excel. В этих программах перехват событий организован по-разному.
В Excel подключенная надстройка загружается как рабочая книга, так что в контейнере ThisWorkbook размещаем предопределенную функцию Workbook_Open(), а в ней включаем перехват событий через специальный класс.
В Word в шаблоне, расположенном в папке Word\STARTUP, создаем модуль AutoExec с процедурой MAIN(), которая запускается при загрузке Word. Перехват событий в ней организуется аналогично Excel.

Особенности реализации перехвата событий в Open Office
В Open Office для всех типов файлов работает единый механизм, организация перехвата событий там требует отдельного описания.

Распечатка документов из СЭД: проблема несовпадения

У нас на заводе автоматизированы несколько бизнес-процессов на Notal System - системе управления задачами и документооборотом. Вот в одном бизнес-процессе - ремонте модельной оснастки - обнаружилась засадливая проблема. Последовательность действий такова (упрощенно):

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

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

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

Что с этим делать? Вариантов несколько.
Радикальный вариант. Полностью отменить бумажные документы и перейти на электронные. Не годится по следующим причинам:

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

В общем, отметаем это решение за излишнюю радикальность.
Автоматизированное порождение конечного документа. Это как распечатка накладной из 1С: там все заполняешь в диалоговом окне, а потом нажимаешь на кнопку [Печать] и формируется печатная форма. Решение тоже не годится - слишком уж вариативно содержание дефекой ведомости, там могут быть и таблицы, и эскизы. То есть если бы дефектная ведомость была бы хорошо формализуемым документом, то она и порождалась бы из системы планирования производства, а не из СЭД. В конце концов, всегда есть такие категории неструктурированных документов - те же письма, к примеру. Надо решать задачу на уровне СЭД при условии, что документ будет редактироваться пользователем в текстовом редакторе или электронных таблицах - грубо говоря, в Ms Office или Open Office.
Административные и воспитательные меры. Что если воспитать/убедить/запугать пользователей, чтобы они отрабатывали правильную последовательность действий до конца? Это сделать надо, конечно, но человек вообще склонен делать ошибки - одна эта мера явно недостаточна.
Модификация функции печати. Что если при печати перехватывать это событие и автоматически обновлять версию документа в СЭД? Вот это - решение! Надо сделать следующее:

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

Осталось научиться перехватывать события печати и открытия документа в Open Office (в Ms Office умею), и запрограммировать клиентскую часть Notal System.

Трекер Notal System: рассылка уведомлений (часть 2)

Интерфейс редактирования наборов критериев

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

• Создать новый
• Копировать (создать новый копированием)
• Редактировать
• Удалить

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

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

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

Интерфейс редактирования одного набора критериев (специальное окно) должен включать в себя две части:

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

Отправка уведомлений по почте и через SMS - общие принципы

Это надстройка для системы, рассылать будем (или не будем) все те извещения, которые есть для пользователя в системе. Никакой дополнительной фильтрации не предусмотрено.

Пользователь сам устанавливает, будет ли он получать уведомления на почту и/или через SMS. Это потребует дополнения информации о пользователе следующими полями:

• Адрес электронной почты
• Мобильный телефон
• Флаг "Получать уведомления на почту"
• Флаг "Получать уведомления через SMS
• Префикс почтовых сообщений (см. ниже)

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

Отправка уведомлений по почте

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

• Текст письма должен содержать ссылку на открытие задачи
• Заголовок письма начинается с префикса (см. след пункт) и содержит аббревиатуру бизнес-процесса и номер задачи
• Префикс письма нужен для возможности настройки пользователем сортировки входящих писем его почтового ящика. Поэтому пользователь может сам задать префикс для уведомлений. Если пользователем префикс не задан, используем "Notal System: ".
• Отправитель - ? Входящая почта все равно приниматься не будет - лучше чтобы не было возможности ее отправить.

Отправка уведомлений через SMS

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

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

Трекер Notal System: рассылка уведомлений (часть 1)

Постановка проблемы

Пользователям полезно оперативно получать информацию о происходящем с задачей, особенно если эта задача не у них на исполнении. К примеру:

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

Все это решается механизмом внутренних уведомлений системы с возможностью отправлять эти уведомления вовне по e-mail или через SMS.

События, которые могут являться основанием для уведомления

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

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

Содержание уведомлений и их хранение

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

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

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

Создание уведомлений: критерии отбора событий

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

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

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

Первый критерий - тип комментария. Мы имеем комментарии трех типов:

• Движение
• Служебный
• Пользовательский

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

Второй критерий - состояние. Мы можем указать конкретное состояние или определенный тип состояния:

• Активное
• Ждущее
• Финальное (без разделения)
• Финальное положительное
• Финальное отрицательное
• Любое состояние
• (Конкретное состояние)

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

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

К каждому комментарию применяются все имеющиеся наборы критериев - даже если удовлетворяет одному, то у другого набора могут быть другие адресаты.

Адресаты уведомлений

В каждом наборе критериев должен быть указан адресат или механизм создания адресатов. Имеем три варианта:

• Конкретный адресат
• По ролям
• По выделенным пользователям задачи

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

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

Третий вариант - указание выделенных пользователей задачи. К выделенным пользователям задачи относятся:

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

Можно выбрать несколько пунктов или не выбирать ни одного.

Второй и третий вариант могут присутствовать одновременно. Эти варианты адресатов доступны при создании рассылки в интерфейсе конфигуратора. Права на создание/редактирование рассылки есть у администратора бизнес-процесса.

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

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

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

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

Интерфейс просмотра уведомлений

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

• Бизнес-процесс
• Тип комментария
• Тип состояния

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

Интерфейс редактирования наборов критериев

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

(продолжение следует)

Open Office Basic - функция Shell

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

Функция Shell и перенаправление вывода в файл

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

РЕШЕНИЕ: написать bat-файл с нужной командной строкой с перенаправлением вывода и уже его вызывать через Shell.

PS. Для таких записок завожу отдельный тег "OO Basic"

Notal System - наш трекер

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

• наглядное представление бизнес-процесса в виде диаграммы состояний - это понятно даже коммерсантам
• веб-интерфейс
• интеграция с офисными программами - Ms Office и Open Office
• наличие API, что позволяет интегрировать с любыми программами, способными отправлять и принимать веб-запросы (у нас на заводе интегрировано с 1С)
• удобно использовать для управления инцидентами - можно реализовать ITIL, к примеру

Некоторые недостатки (временные, разумеется):

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

В общем, есть куда развиваться. Да, если вам интересно попробовать поработать с Notal System, то пишите мне на notal@nm.ru - сделаем вам свою базу, срок пробного использования два месяца.

Управление временем в трекере

1. Постановка проблемы

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

2. Что есть исполнение планового срока?

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

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

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

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

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

Назначение события как факта исполнения делаем не для задачи, а для диаграммы. Т.е. мы не можем установить, что задача 1 считается исполненной при попадании в состояние 7, а задача 2 - при попадании в состояние 5; нет, правило устанавливается на уровне диаграммы: задача считается исполненной при попадании в любое из состояний 5, 6, 8. Реализовать это можно установкой флажка в состоянии.

3. Виды сроков

Срок типа "конкретная дата" не очень удобен - для отдаленных планов это слишком большая конкретика, удобнее планировать "в ноябре", "в 3 квартале" и т.п. Фактически задаче мы назначаем интервал времени. Поскольку задачи понимаются как нечто достаточно элементарное, то для крупных временных интервалов можно считать, что задача должна начаться и завершиться в этом периоде (требуется еще продумать этот момент).
Мы рассматриваем следующие календарные сроки:

• Дата
  
• Неделя (№ недели в году + год)
  
• Месяц (+ год)
  
• 1-4 неделя месяца (экзотика, но у нас используется в планировании производства)
  
• 1-3 декада месяца (у нас не используется и пока не делаем)

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

• этапы рассматриваются сразу рядами: А1, А2 ... Аn. Относительно этапов в ряду считаем, что они идут один за другим и не пересекаются. Нам потребуется несколько рядов этапов для того, чтобы иметь возможность планировать независимые проекты.
  
• каждый этап имеет дату начала и дату конца (привязка к календарю), но они могут быть и на начальном этапе планирования будут пустыми. То есть мы создаем ряд этапов, раскидываем задачи проекта по этапам и потом устанавливаем конкретные даты этапам, причем не обязательно всем - можно только начальным, а более поздние пока без календарной привязки.
  
• для ряда этапов устанавливаем единую плановую длительность этапа - две недели, месяц - как выберем.

4. Назначение сроков задаче

Задаче могут быть назначены несколько сроков из разных рядов: к примеру, месяц Март и 12-я неделя года, этап А3 и этап В8. Из каждого ряда может быть назначен только один срок (что естественно, поскольку периоды в ряду не пересекаются). При назначении срока проверяем, не вступает ли он в конфликт с уже назначенными сроками: так при назначении срока "12-я неделя" мы должны проверить, что она пересекается со сроком "Март".
При назначении этапов А3 и В8 если у них указаны даты начала и конца, то проверяем, если не указаны - можем назначать.
По сути сроком задачи будет пересечение всех назначенных ей сроков, т.е. для задачи можно вычислить дату начала и дату конца. Эти даты не редактируются вручную, а пересчитываются при назначении срока задаче (в том числе при отцеплении задачи от ранее назначенного срока: был Март, сменили на Апрель или вообще убрали привязку к месяцу).
Дата начала не несет особого смысла - мы можем начать задачу и раньше, можем и позже. Важной является лишь дата конца и именно по ней мы будем определять, уложилось ли фактическое выполнение (см. п. 2) или нет.

5. Назначение срока этапу

Сроки этапов подчиняются следующим правилам:

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

Второе правило рассмотрим подробнее. При назначении дат начала и конца этапу они должны быть такими, чтобы ни у одной из входящих в этап задачи не возникло несовместимых сроков. Для этого по всем срокам всех задач этого этапа считаем C1 = max(ДатаНачала_k) и C2 = min(ДатаКонца_k). Условиями совместимости дат этапа с уже назначенными сроками будут:

ДатаНачалаЭтапа < C2
ДатаКонцаЭтапа > C1

6. Специальные операции с рядами этапов

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

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

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

7. Взаимозависимость задач

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

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