74
менеджмента заказчика, многие из которых привели к изменениям в архитектуре
приложения. Много времени потрачено на коммуникацию между заказчиком и
исполнителем и в процессе тестирования. Очень долго заказчик выполнял
тестирование промежуточных и финального результатов. Заключив
дополнительные соглашения к договору, компенсировались все издержки со
стороны заказчика [9].
2.2.2 Формирование команды проекта автоматизации
Соблюдение баланса между работой, временем на ее выполнение и
затратами накладывает огромную ответственность на выполнение проекта.
Одновременно с соблюдением этих трех факторов, также необходимо
максимально удовлетворить потребности заказчика.
К участникам относят людей и предприятия, принимающие активное
участие в реализации проекта. Также участниками принято считать тех, чьи
интересы напрямую затронуты результатами выполнения или окончания проекта.
Участники проекта являются его основой, потому что именно они
реализовывают замысел проекта. В зависимости от масштабов, типа и сложности
проекта, в нем могут участвовать от одного до десятка предприятий. Каждый
имеет собственную степень и перечень функций, применяемых на определенном
этапе ЖЦ проекта. Все без исключения участники проекта, исходя из
выполняемых функций, объединяются в определенные категории.
Для реализации системы электронного документооборота выбрана
следующая команда:
1. Инициатор-проектировщик - автор идеи проекта. В нашем случае
студент-выпускник.
2. Заказчик - является главным участником проекта, и в будущем
владельцем и/ или пользователем проекта. В нашем солучае это банк.
3. Руководитель – руководитель с ВУЗа, который проверяет работу.
4. Тестировщики – лица с предприятия заказчика, которые будут проводить
тестирование системы электронного документооборота.
75
2.2.3 Средства коллективной работы над проектом
автоматизации
Средства коллективной работы будут отвечать выбранной методолгии в
2.2.1.
Гибкие методологии по управлению проектами, которые базируются на
формировании бизнес - ценности для заказчика при постепенной итеративной
разработке продукта надежно вошли в проекты в области IT. Доказана их
эффективность в условиях неопределённости, которой сопровождается бизнес
сегодняшнего времени.
На подготовительной стадии проведен первоначальный анализ проблемной
ситуации: выполнен обзор зарубежных и российских публикаций, относящиеся к
данной теме. Также проведено неструктурированное интервью трех менеджеров
проектов в сфере IT, которые имеют опыт работы с Agile. Итогом данной стадии
явилась формулирование гипотез изыскания и создание вопросника для сбора
информации в дистанционном режиме.
На втором этапе изыскания осуществлялся сбор информации при помощи
дистанционного опроса экспертов из сферы IT посредством интернета. С этой
целью опросник, который был создан на предшествующем этапе, размещался в
группах социальных сетей, на тематических форумах с применением сервиса
Google Docs.
Анализировалась полученная информация при помощи SPSS. Особое
внимание обращалось на анализ корреляций и построение регрессионных
моделей.
На стадии формулирования рекомендаций была осуществлена подготовка
методических рекомендаций для практиков по управлению проектами. Даны
конкретные предложения для разнообразных сфер знаний.
Ориентирование на удовлетворение потребителя – один из основных
принципов Agile. эффективное введение методологии считается единственным
вариантом, чтобы данный принцип привить команде.
Следовательно, переход на гибкие методологи можно представить таким
алгоритмом. Менеджером анализируется текущая ситуация на предприятия,
исследуются процедуры реализации продукта. Потом на основании
приобретенных данных вырабатывается план, какие подходы следует применить
76
для решения обнаруженных проблем (для каждого предприятия план будет
персональный). Далее выполняется постепенное осуществление разработанного
плана. Очередной этап заключается в проверке, насколько предложения оказались
успешными, насколько отклонение от плана было сильным. По результатам
данного этапа план корректируется [9].
Этот цикл несколько раз повторяется, поскольку внедрение является
достаточно долгим процессом. Это дает возможность выполнять изменения
небольшими шагами, стабильно контролируя итоги и направляя процесс.
Представителем таких инструментов считается нулевая итерация (iteration
zero). Этот подход состоит в применении первой итерации не с целью разработки,
а с целью предварительной подготовки. В процессе перехода с традиционной
методологии на гибкие методологии по разработке интернет - вещей данная
итерация используется, чтобы перевести привычный план в backlog проект,
являющийся списком необходимых технических свойств и заданий проекта на
текущий момент. По итогам нулевой итерации законченный продукт не
вырабатывается, а создаются достаточные и необходимые и условия для начала
реализации. Этот метод не следует воспринимать в качестве полноценной
проработки и планирования как в традиционной методологии. В этом случае все
приготовления заключаются в минимально необходимых действиях, поскольку
все изменится в процессе осуществления проекта. С течением времени команда
может постепенно уменьшать продолжительность нулевой итерации до того
момента, когда сможет полностью отказаться от неё [20].
В agile методологиях, обычно, оценка и контроль работы команды
осуществляется в процессе ретроспективы. После каждой итерации
осуществляется первоначальная ретроспектива. В это время вся команда
собирается, для разбора результатов итерации, выявления проблем и определения
методов их решения. Впрочем, на практике зачастую получается, что провести
ретроспективу в конце затруднительно: у команды слишком мало времени,
многие проблемы были решены еще в процессе итерации. Поэтому изредка
наиболее подходящим считается подход, применяющийся многими agile
консультантами и практикующими менеджерами – непрерывной (continuous)
ретроспективы. Главная суть данного подхода к ретроспективе заключается в
77
переносе процесса на каждодневные «stand-up» собрания: визуализации каким-
либо методом проблемы и процессе реализации, и решении их на месте. Имеется
большое количество различных методов визуализации, наиболее
примечательными считаются – Доска идей, Value stream mapping.
VSM (Value stream mapping) – метод, пришедший из lean management.
Метод является некоторой схемой этапов и событий, которые проходит продукт,
прежде чем поступит к потребителю. Этот метод предоставляет возможность
визуализации процесса формирования бизнес - ценности продукта. Данный
подход, как правило, применяют в производстве, впрочем, он считается хорошим
и для создания ПО. Формирование бизнес - ценности считается краеугольным
камнем гибких методологий, поэтому визуализация такого процесса
предоставляет команде превосходное понимание того, что в проекте происходит.
Достаточно «прикрепить» возникнувшую проблему к определенному месту
появления на VSM, для представления о том, какое значение имеет процесс, в
котором появилась проблем, и к каким последствиям это приведет. Располагая
такой информацией в реальном времени можно решать проблемы на
каждодневных собраниях.
Доска идей – считается аналогом доски задач. Предоставляет возможность
визуализации проблем и их решений, а также реализации улучшений и
предложений аналогично задачам. Все компоненты расположены в 3 зонах:
запланировано, в исполнении, выполнено. Этот метод в отличие от VSM, не дает
возможности увидеть взаимосвязи, но обеспечивает отличную визуализацию и
упрощает контроль процесса решения проблем и введения улучшений. На
повседневных собраниях команда, совместно с задачами, обговаривает и статус
компонентов на доске идей, что позволяет помнить об улучшениях и проблемах,
не отодвигать их до завершения итерации, а решать сейчас и здесь.
В таблице 8 представлены возможности некоторых коммерческих средств
коллективной работы.
VC – поддержка контроля версий; Cnf – автоматизация разрешения
конфликтов; Brn – поддержка ветвления версий; Shr – возможность
использования одного файла в нескольких проектах; Net – доступ к БД проекта по
сети (TCP/IP); FS - доступ к БД проекта с использованием файловой системы; Srv
78
– серверный ли тип этой СКР (S - серверный, W - бессерверный, B - работа в обоих
режимах); Cmd – наличие интерфейса командной строки; GUI – наличие
графического интерфейса; jc - автоматизация управления распределением
обязанностей; bc - контроль и ускорение сборки проекта; bt - встроенная система
поиска ошибок; + имеется; - отсутствует; = имеется в большинстве поставок;
* поддерживается внешними средствами; ~ не удалось получить точных сведений.
Таблица 8
Коммерческие средства разработки
Название
программы
VC
Cnf
Brn
Shr
Net
FS
Srv
cmd
GUI
jc
Bc
Bt
Jira
+
+
+
-
+
-
S
+
-
+
-
-
Merlim
+
-
+
+
+
+
S
-
+
-
~
+
Slack
+
+
+
~
+
+
S
+
+
+
+
~
Bacecamp
+
+
-
-
*
+
W
-
+
-
-
-
Asana
+
-
+
-?
+
+
S
-
+
-
-
-
Trello
+
-
-
-
-
+
S
=
+
-
-
-
Gemini
+
+
+
~
+
+
S
~
+
+
-
+
ManagePro
+
+
+
-?
-
+
S
-
+
-
-
-
Bitrix24
+
+
+
-
-
+
S
+
=
-
-
-
Tribe
+
+
+
+
*
+
S
+
+
-
-
-
2.3. Информационное обеспечение задачи
2.3.1 Информационная модель и её описание
Как модель информации применяем схему данных. Данная схема (ГОСТ
19.701-90) информации указывает информационный путь при выполнении задач
и назначает этапы обрабатывания, а также различные применяемые носители
данных. Всю процедуру информационной обработки можно поделить на два
этапа:
1. Прием, введение и обработка первичной входящей информации
(организационные данные, паспортные данные и пр.).
2. Создание отчетов и документов (перечни сотрудников, клиентов и пр.).
Визуальное представление модели информации представлено на рисунке
13.
79
Рисунок 13 Информационная модель
2.3.2 Характеристика нормативно-справочной, входной и
оперативной информации
Для создаваемой системы входящей информацией будут считаться
клиентские документы (паспорт), а также разные специальные документы,
применяемые в наследственном делопроизводстве. Вся эта информация
поступает и в бумажном виде, и цифровом.
Из входящих документов вся информация вносится в систему ручным
вводом через Web-интерфейс.
Из клиентского паспорта в систему вносятся следующие данные:
-·Фамилия, имя, отчество клиента;
-·Пол;
-·Место рождения;
-·Дата рождения;
-·Индигенат;
-·Паспортный номер и серия;
80
-·Когда и кем был выдан паспорт;
-·Номер телефона.
Из документальных атрибутов в систему вносятся такие сведения:
- название документа;
- число страниц;
- дата подготовки;
- электронная копия;
- вид документа (входящий, исходящий, внутренний);
- адресат.
В таблице 9 находятся показатели, которые выделены в пределах комплекса
задач.
Таблица 9
Входящие показатели в пределах комплекса задач
№ п/п
Название входящего показателя
Идентификатор
входящего
показателя
1
Общее число клиентских регистраций
R
i
2
Число документов в i-го типа
Z
i
3
Общее число документов
N
Описание классификаторов показано в таблице 10.
Таблица 10
Сводная таблица применяемых классификаторов и систем шифрования
№
п/
п
Название
шифруемого
множества
Кодовая
значимос
ть
Система
шифрован
ия
Система
классификац
ии
Тип
классификато
ра
1
Клиентский код
5
порядкова
я
отсутствует
локальный
2
Документальный
код
5
разрядная
отсутствует
локальный
Эскизы входящей информации представлены на рисунке 14.
81
Рисунок 14 Эскиз формы регистрации пользователя
2.3.3 Характеристика результатной информации
Результативной информацией в системе документооборота является
отчеты о количесве документов того или иного типа, отчет о всех документах и
отчет по клиентам. Эскиз получения результатной информации представлен на
рисунке 15.
Рисунок 15 Эскиз формы получения результатной информации
2.4. Программное обеспечение задачи
2.4.1 Общие положения (дерево функций и сценарий диалога)
Дерево функций разрабатываемой системы изображено на рис. 16.
Фамилия Поле ввода данных Подсказка
Имя Поле ввода данных Подсказка
Отчество Поле ввода данных Подсказка
Должность Поле ввода данных Подсказка
адрес Поле ввода данных Подсказка
телефон Поле ввода данных Подсказка
Submit
Кнопка отправки формы
Наименование Выпадающий список Подсказка
Submit
Кнопка отправки формы
Экспорт в Excel
82
Рисунок 16 Дерево функций системы
Диалоговый сценарий пользователя представлен на рисунке 17.
Авторизация
1. Главное меню
2. Выход
Главное меню
1. Регистрация
2. Списки
3. Архив
4. Выход
Регистрация
1.Клиенты
2. Документы
Списки
1. Входящие
2. Исходящие
3. Внутренние
4. Клиенты
Архив
1. Входящие
2. Исходящие
3. Внутренние
4. Клиенты
5. Поиск по архиву
Рисунок 17 Сценарий диалога
83
Главный сценарий применения системы следующий.
При клиентском обращении секретарь регистрирует его, применяя
предъявленные им документы. Во время делопроизводства секретарь также
производит регистрацию документов, загружая на сервер их электронные копии,
которые получены посредством сканирования.
Секретарь также может редактировать список клиентов, просматривать
дополнительные сведения о каждом из клиентов, а также помещать неактуальные
документы в архив. Помимо этого, доступен перечень удаленных клиентов и
поиск в архиве документов.
2.4.2 Характеристика базы данных
ER-модель созданной информационной базы представлена на рисунке 18.
Рисунок 18 ER-модель разрабатываемой базы данных
Дальше определим для каждой из таблиц тип поля и формат содержащейся