45
Этап внедрения часто тоже бывает продолжителен, если заказчик не может
сразу остаться довольным продуктом, да и сами сотрудники компании-заказчика
могут с недоверием отнестись к новому ПО.
Для сокращения рисков в данной ситуации проводят качественное
обучение сотрудников еще до периода эксплуатации, готовят отдел
сопровождения и поддержки, понимают, что может произойти в процессе
эксплуатации и как можно найти верное решению. Иметь возможность ответить
на возникающие вопросы или открыть горячую линию для решения
поступающих проблем.
Среди явных проблем процесса создания проекта можно выделить такие:
• Корректировка требований относительно процесса создания;
• Разделение ответственности за реализуемую работу и ее результат;
• Доступность потока мелких, срочных, приходящих требований,
отвлекающих программистов и управленцев от базового направления работ.
• Срыв срока, повышение расходов, потери качественного уровня.
Чтобы реализовать успешную организацию процесса создания,
подготовлена универсальная процедура создания проектов.
Модели, методики и подходы универсального управления проектами
имеют свое развитие в рамках сложных технических проектов, которые
заключаются в реализации больших программных комплексов. Универсальное
управление можно рассматривать как некую платформу, которая находится в
рамках нескольких методик контроля инновационными, а самое важно, ИТ
проектами. Базовая суть универсального управления проектами описана в
работах Дж. Хайсмита [1], Г. Аллемана [8], Г. Чина [11]. Сравнение разных
прикладных методологий универсального управления новейшими проектами
также есть в трудах К. Лармана [27] и П. Абрамсона и других [5]. Моментный
подход к определяю наилучшей методики универсального управления
проектами указан ив работе А.С.Коха [3].
Дж. Хайсмит выделяет базовое качество данного подхода так: «Гибкость
(аgility) - это возможность сразу и создавать, и отвечать на корректировки,
46
создавая прибыль в изменчивых условиях экономики. Гибкость становится
способностью держать баланс между стабильностью и хаосом» [16]. Также он
пишет, что: «Часто многие склонны верить, что подвижность говорит об
отсутствии структуры. Но такое отсутствие порождает хаос. Также, избыток
некой упорядоченности несет за собой жесткость. Теория сложности описывает
то, что процесс создания инновации методами, которые не определены заранее,
часто реализован в точке соприкосновения порядка и хаоса, гибкости и
стабильности. По словам ученых, реализация нового возможна на границе хаоса
[16]. Но на нахождение такого баланса между порядком и хаосом и будут
направлены все возможности универсального управления проектами. Причем
следует оно от упорядоченности процессов, инструментов и методик, которые
есть в традиционных школах проектного управления в рамках деконструкции,
деструктуризации множественных упорядоченных реализованных условий
протекания проектов, к выработке понятных и логичных (направленных на
персонал методов и инструментов, которые имеют возможность плавно
приспособиться к изменчивым условиям). Если классическими параметрами
управления проектами описывались планирование, улучшение и отслеживание,
то универсальное управление проектами основными усилиями будет считать
естественную эволюцию и приспособление.
В 2001 году основатели и последователи части близких по духу и сути
методик управления ИТ-проектами создали свод правил универсального
контроля проектами. Данный свод описал 4 базовые идеи и 12 параметров [17].
Создатели свода правил, почитатели методик экстремального
программирования, скрама, адаптивного создания проектов и т.п., сознательно
не стали сводить универсальное управление проектами к моделям,
инструментарию и средствам, но отразили его в виде неких адаптационных идей
и принципов, которые нужны для понятного творческого воплощения в
контексте отдельной ситуации. Суть и идеи универсального проектного
управления не нужно сводить к сложившимся законам и правилам.
Базовая основа универсального управления заключена в:
47
• Персоналии и их работа важнее, чем инструмент и процесс;
• Применяемое ПО (в общем случае - ценный для клиента продукт или
реализуемая услуга) важнее, чем собранное документальное сопровождение
(или контроль плана бюджета);
• Работа с заказчиком важнее, чем обязательства по контракту;
• Реакция на коррективы важнее, чем простое следование плану.
Суть универсального управления проектами состоит их:
• Удовлетворенность клиента благодаря оперативной и надежной
разработки продукта, который имеет значение для клиента;
• Позитивное отношение к корректировке требований к продукту,
даже на финальной стадии, если это имеет значимую ценность для клиента и
ведет к росту конкурентных качеств продукта;
• Создание и поставка отдельно работающих модулей или
обновленных версий ПО (ежемесячно, еженедельно или чаще);
• Полноценное общение с заказчика с разработчиками в рамках всего
проекта, выходящее за рамки только контрактных обязательств;
• Повышенная мотивация участников проекта, имеющих все
требуемые материалы и средства, поддержку и доверие;
• Персональный разговор, как базовый метод передачи данных в
рамках проекта;
• Функционирующий и ценный для клиента продукт как лучший
индикатор успеха проекта;
• Все участники проекта, в особенности создатели и вдохновители,
должны без проблем поддерживать конкретный темп работы на требуемый срок;
• Рост технического мастерства исполнителей и улучшение самого
продукта;
• Переход к простоте, чтобы не реализовывать лишнюю работу;
• Самоорганизация и автономия на уровне команды проекта,
оптимальные тех. требования, дизайн и архитектура реализуются у лучше
организованной команды;
48
• Доступность изменений при смене обстоятельств.
Принцип схемы универсального управления проектами признается
циклическая модель ЖЦ проекта, которая разбивает проект на несколько
процедур. «Каждая процедура выглядит как некий программный файл в
миниатюре, и состоит из задач, которые нужны для реализации мини-прироста
по скорости работы: изучение требований, составление плана, проектирование,
написание кода, проверка, документирование. Каждая отдельная процедура
зачастую не так оправдана для реализации обновлённой версии продукта, тут
понимается, что сам по себе проект готов к реализации по факту каждой
процедуры. В рамках окончания каждой процедуры команда проводит
переоценку основных задач разработки» [14].
2.2 Информационная модель и её описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области.
Кроме того, она объясняет, на основе каких входных документов и какой
нормативно-справочной информации происходит выполнение функций по
обработке данных и формирование конкретных выходных документов.
Информационная модель представлена на рисунке 10.
49
ИС
Т права
доступа
Спр Отделы *
Спр виды
документ ов
Т права
доступа *
Спр разделы
Спр
Пол ьзователи*
Спр статусы
документ ов
Спр виды
документ ов*
Т фа й лы
Спр
Номенклатура
*
Т папки
Спр Пап ки*
Администратор
Перечень отделов
Спи со к
сотрудников
Номенклатура дел
Учет отделов
Учет
пользователей
Составление
номенклатуры
Учет видов
документ ов
Учет прав
доступа
Сотрудник
Документ
Регистр ац и я
док умента
Создание папки
Спр
пользователь
Т документы
Т Фай л*
Т Док умент*
Спи со к
сотрудников
Номенклатур
а дел
Спи со к
документ ов,
находящихся
в архиве
Спи со к
документ ов
по видам
АдминистраторСотрудник
Спр от дел ы
Спр Ра здел ы *
учетная
карт очка
док умента
Рисунок 10 Информационная модель системы
документооборота
В соответствии с приведенной информационной моделью, работа системы
осуществляется следующим образом.
Администратор системы регистрирует сотрудников, используя и изменяя
содержимое справочника «Пользователи». При необходимости администратор
добавляет данные в справочники Папки, Номенклатура, Типы документов, Роли,
Адреса, Отделы.
Сотрудник регистрирует документы, используя документ и справочник
«Типы документов», Роли, Номенклатура, Папки и изменяя содержимое таблиц
Документы и Файл.
Администратором системы на основании входных документов
заполняются следующие справочники:
50
• отделы;
• роли пользователей;
• пользователи;
• виды документов;
• номенклатура.
Для заполнения справочников используются соответствующие экранные
формы, а именно:
• учет отделов;
• учет ролей;
• составление номенклатуры;
• учет видов;
• учет пользователей;
Данные сведения сохраняются в таблицах с первичными данными,
наименования которых совпадают с наименованиями справочников.
Далее используется экранная форма регистрация папки и документа. При
этом используются данные всех системы справочников, указанных ранее. В
результате информация о документах и папках сохраняется в справочнике Папки
и таблицах Документы и Файл[35].
Затем администратор и пользователь системы получает на экран состав
справочников, а также список документов и папок. При этом используются
данные из всех справочников системы и таблицы Документы. При
необходимости данные документы можно вывести на печать.
В качестве входной информации в разработанной системе
документооборота используются следующие документы и сведения:
− Перечень отделов предприятия;
− Список сотрудников предприятия;
− Номенклатура дел.
Данные документы вносятся в систему вначале ее работы.
В системе используются справочники, приведенные в таблице 10.
51
Таблица 10
Перечень используемых справочников
№
п
п
название
справочника
ответственны
й за ведение
средний
объём
справоч
ника в
записях
среднюю
частоту
актуализац
ии
средний
объем
актуализаци
и, %
1
Отделы
Администратор
100
1 раз в месяц
10
2
Роли
пользователей
Администратор
10
1 раз в год
10
3
Пользователи
Администратор
200
1 раз в год
10
4
Типы
документов
Администратор
500
1 раз в месяц
25
5
Номенклатура
Пользователь
200
1 раз в год
25
6
Папки
Пользователь
250
ежедневно
25
Справочник Отделы включает в себя название отдела. Справочник Роли
пользователей включает наименование роли пользователя, а также
определенные права на чтение, добавление или удаление документов, файлов,
папок. В справочнике Пользователи содержатся следующие сведения:
− Фамилия
− Имя и отчество
− Должность
− Логин
− Пароль
− Дата регистрации
− Дата рождения
− Роль пользователя
Справочник Номенклатура составляется в ходе использования
номенклатуры дел бумажного документооборота и содержит следующие
реквизиты:
− Наименование записи (дела) в номенклатуре
− Количество томов
− Номер тома
− Страниц всего
− Дата добавления
52
− ФИО добавившего пользователя
− ФИО удалившего пользователя
Справочник Папки является справочником, который содержит сведения о
создании каждым пользователем иерархии обрабатываемых документов. Также
каждая папка может быть в той или иной степени открыта для чтения и записи
другими пользователями, либо вообще закрыта.
Данный справочник содержит следующие реквизиты:
− Наименование папки
− ФИО добавившего пользователя
− Дата добавления
− Права доступа
− Изображение
Оперативная информация хранится в таблицах Документы и Файлы. В
таблице Документы хранятся все сведения о зарегистрированном документе, а
именно следующие реквизиты:
− Номер документа
− ФИО сотрудника
− Наименование
− Вид документа
− Дата подготовки
− Дата и время регистрации
− Количество страниц
− Примечание
− Адресат
− Статус
− Права доступа
В ходе деятельности к документам могут прикрепляться различные файлы,
в том числе и их электронные копии. Сведения о таких файлах содержатся в
таблице Файлы, в которой учитываются нижеперечисленные реквизиты:
53
− Номер файла
− Наименование файла
− Путь к файлу на сервере
− Размер в кб
− Дата добавления
− ФИО пользователя, добавившего файл
− Код документа, к которому прикреплен файл
− Права доступа
− Тип файла (расширение)
Результатной информацией для задачи автоматизации делопроизводства
являются следующие документы:
− список сотрудников;
− список документов по видам;
− номенклатура дел;
− учетная карточка документа;
− список документов, находящихся в архиве.
Список сотрудников приведен на рисунке 11.
Рисунок 11 Список сотрудников
В списке сотрудников имеются следующие реквизиты:
− фамилия, имя, отчество сотрудников;
54
− дата регистрации;
− должность;
− отдел;
− дата рождения;
− логин и пароль для доступа в систему.
Данный документ формируется на основе справочников Отделы,
Пользователи.
Списки документов имеют следующие реквизиты:
− наименование документа;
− дата регистрации;
− краткое описание;
− количество страниц;
− адресат;
− ссылка на электронную версию документа.
Экранная форма списка документов приведена на рисунке 12.
Рисунок 12 Экранная форма списка документов
Список документов, находящихся в архиве, а также список документов,
находящихся на контроле, отличаются статусом. При этом в системе могут быть
следующие статусы:
− документ зарегистрирован;