37
В указанных программных средствах присутствует примерно равный
функционал. А именно:
1. Создание карточек задач;
2. Перемещение задач между этапами ("Запланировано", "В работе",
"Готово");
3. Прикрепление исполнителей к задачам;
4. Отслеживание задач.
Данный функционал крайне необходим при использовании так
называемых "канбан-досок", чем по факту данные продукты и являются. Они
позволяют заводить задачи, перемещать их по статусам готовности, назначать
ответственных и разумеется вести статистику. Однако, в рамках поставленных в
бизнесе-процессе задач этот функционал не отвечает требованиям, а в некоторых
случаях избыточен.
Примером избыточного функционала в случае "Норс Студиос" является
возможность прикрепления исполнителей задач. В пайплайне (разъяснение
приводится далее по тексту) компании предусмотрено использование малых
команд, которые отвечают за строго определенный набор задач, которые
необходимо решать. Для определения таких задач существуют в компании так
называемые "Флоу" (от английского Flow - поток). Каждая команда отвечает за
свой Флоу, а каждый сотрудник команды отвечает за свой этап данного Флоу.
Таким образом получается некий трубопровод (отсюда и понятие пайплайна -
английское Pipeline переводится как трубопровод), на каждом вентиле которого
находится определенный сотрудник.
Отсюда можно сказать, что используя вышеописанные средства,
компании тем не менее придется использовать отдельно взятого сотрудника для
формирования дорожной карты проектов, поскольку механизм канбана не
позволяет в полной мере осуществлять контроль исполнения задач в
долгосрочной перспективе и на базе полных сведений о проекте (например, для
того, чтобы оценить текущие успехи и будущие цели проекта необходимо будет
38
просмотреть или несколько канбанов или же заранее сформировав удобно
отсортированный список).
Соответственно, в данном дипломном проекте должна быть
осуществлена разработка технологии автоматизации процесса экспортирования
задач в дорожную карту для автоматизации контроля их исполнения в проектах
"Норс Студиос", что, в свою очередь, ускорит процесс публикации обновленных
сведений, снизит риск утечки информации, которая не должна быть
предоставлена никому кроме сотрудников компании, и повысит обратный отзыв
о деятельности компании со стороны конечного потребителя. При этом
руководство компании получит удобный инструмент для контроля этой
деятельности.
1.3.2 Выбор и обоснование стратегии автоматизации задачи
Стратегией автоматизации задачи в случае с компанией "Норс Студиос"
была выбрана стратегия автоматизации по участкам, поскольку она позволяет
автоматизировать задачу с минимальными финансовыми вложениями и дает
сильный экономический эффект за счет последующего уменьшения штата
сотрудников.
Данная стратегия позволяет автоматизировать одну из задач в бизнес-
процессе, что в свою очередь в случае компании "Норс Студиос" также в
значительной мере изменит и сам бизнес-процесс. Это задача выгрузки данных
из единого реестра задач в компании с последующим формированием дорожной
карты. Данная задача тесно связана с другими задачами в бизнес-процессе, а
именно:
1. Создание задач;
2. Контроль исполнения задач;
3. Публикация дорожной карты.
В данный момент эта задача выполняется отдельным сотрудником
(копирайтером) и изредка привлечение сторонних сотрудников для уточнения
деталей по задачам.
39
Выбор этой стратегии обуславливается следующими причинами:
1. Значительное снижение ресурсозатрат компании при
автоматизации контроля исполнения задач по проектам;
2. Повышение оперативности публикации обновленных данных.
1.3.3 Выбор и обоснование способа приобретения ИС для автоматизации
задачи
Существует несколько различных способов приобретения
информационной системы для автоматизации поставленной задачи. К ним
относятся:
1. Приобретение стороннего готового решения в виде самодостаточного
программного обеспечения;
2. Приобретение стороннего самодостаточного программного
обеспечения с дальнейшей доработкой;
3. Приобретение стороннего решения в виде индивидуальной разработки
программного обеспечения под нужды и условия компании;
4. Приобретение продукта в виде собственной внутренней разработки
программного обеспечения.
Среди представленных решений, исходя из уже высказанного в данной
дипломной работе анализа существующего программного обеспечения, можно
сразу вычеркнуть вариант с приобретением готового продукта, поскольку таких
на рынке в данный момент не представлен.
Приобретение стороннего продукта с последующей доработкой также
является не оптимальным вариантом, поскольку бóльшая часть представленного
на рынке программного обеспечения является закрытым проприетарным
решением, внесение изменений в который не предусматривается продаваемым
лицензиям. Покупка с последующей разработкой модуля расширения же в свою
очередь обойдется в значительную сумму и в конечном итоге приведет к тому,
что разработка собственного решения будет экономически выгоднее.
40
Если обращаться к индивидуальной разработке, то стоит обратить
внимание на наличие корпоративной экосистемы и огромное количество
требований к реализации. Это приведет к значительному повышению цены
готового продукта и необходимого на его реализацию времени, поскольку
сторонней компании необходимо ознакомится со всеми требованиями,
экосистемой и рутине сотрудников (иначе говоря понять UX компании).
Собственная разработка имеет позитивный опыт, если говорить о
разработке внутри экосистемы и пользовательском опыте. Однако собственная
разработка занимает большое количество внутренних ресурсов компании,
включая не только инженеров, но и техническое обеспечение.
Основываясь на вышесказанном, была разработана сравнительная
таблица, представленная в таблице 6. Для оценки используется пятибалльная
система, где 5 - наивысший балл, а 1 - наименьший. Наиболее оптимальное
решение находится путем поиска максимума из сумм всех строк у каждого
варианта
Таблица 6
Сравнительный анализ способов приобретения
Вариант
приобретения
Расширяемость
Модульность
Стоимость
разработки
Время
разработки
Внедрение в
экосистему
Готовое решение
1
3
4
5
2
Готовое решение
плюс доработка
2
4
3
2
3
Заказное решение
4
3
1
1
4
Собственная
разработка
5
5
2
3
5
Исходя из полученных сведений можно сказать что самым оптимальным
решением будет разработка программного обеспечения собственными силами и
41
ресурсами компании, а учитывая основную деятельность предприятия
(разработка программного обеспечения) можно быть уверенным в качестве
разрабатываемого продукта и его полное соответствие потребностям компании.
1.4. Обоснование проектных решений
1.4.1 Обоснование проектных решений по информационному обеспечению
По выясненным ранее причинам было выбрано проектное решение,
включающее в себя собственную разработку программного продукта. К данным
причинам относятся:
1. Отсутствие на рынке готового решения удовлетворяющего
потребностям компании;
2. Необходимость возможности гармоничного встраивания в экосистему
компании и пайплайны сотрудников;
3. Необходимость интеграции с внутренними продуктами (встраивание в
экосистему с обратной связью);
4. Глубокое понимание внутренних процессов компании;
5. Функциональная независимость от сторонних компаний как
дополнительная причина, способствующая повышению безопасности
информационных активов.
Для информационного обеспечения реализации поставленной задачи
необходимы следующие объекты:
1. Входные и выходные документы;
2. Графический интерфейс соответствующий дизайн-линии компании
для ввода необходимой информации из входных документов,
настройки метода их обработки и вывода результирующих данных о
статусе обработки поданной информации;
3. Классификация и кодирования документов;
4. Информационная база данных;
42
5. Программные серверы для получения, обработки и сохранения
информации, интегрированные в экосистему компании.
В рамках решаемой задачи входными документами являются
предоставляемые руководством проекта требования к обновлению
программного обеспечения, разрабатываемого в рамках проекта (что должно
входить в новую версию программного продукта) и сведения о проекте, в
которых описывается проект, его этапы, сроки выхода обновлений продукта в
рамках проекта и иная информация, необходимая разработчику для определения
тонкостей задачи.
Выходными данными является готовая дорожная карта, в которой будет
представлена информация по проекту, его обновлениям и их срокам,
выполняемым в рамках этих обновлений задач. Помимо этого, здесь же будут
указываться текущие состояния задач и вхождений в них.
Графический интерфейс должен отвечать за взаимодействие программы
с пользователем, в результате которого программное обеспечение будет в
первом случае получать необходимую для обработки информацию и выдавать
результаты, а во втором демонстрировать готовые результаты без возможности
добавления, редактирования или удаления. За конфигурацию взаимодействия
должна отвечать внутренняя система аутентификации пользователя. Для ввода,
вывода или любой формы изменения информации необходимо определить
макеты форм, которые будут за это отвечать.
Графический интерфейс должен отвечать всем требованиям внутренних
документов, включая и не ограничиваясь дизайн-документом и
брендинг-руководством.
Системой классификации и кодирования документов будет служить уже
существующий в компании "Норс Студиос" классификатор, входящий в состав
внутрикорпоративной методологии разработки. Данное решение принимается на
основе того, что существующий классификатор в полной мере и объеме
43
удовлетворяет потребностям, возникающим во время реализации решения,
представленного в данном дипломном проекте.
Информационная база данных должна быть централизованной для
обеспечения однородности получаемой, обрабатываемой и выдаваемой
информации. Управляться база данных должна при помощи системы управления
базами данных, а добавляться и изменяться любым образом информация должна
при помощи специального сервера базы данных.
Для динамического масштабирования программного решения, равно как
и для оптимизации используемых ресурсов, необходимо использовать
микросервисную архитектуру, которая позволяет активно манипулировать и
заменять все элементы функционирующего программного обеспечения во время
непосредственной работы (так называемый "горячая замена"). Для этого,
серверная часть программного обеспечения должна быть разбита на несколько
малых серверов, каждый из которых отвечает за свою небольшую задачу. К
таким серверам будут относиться:
1. Сервер Базы Данных;
2. Сервер Сети Доставки Контента;
3. Центральный Сервер Обработки Данных.
Необходимо также предусмотреть возможность дальнейшего
расширения и подключения программного обеспечения во внутреннюю
экосистему компании. Примером такой интеграции служит использование
внутреннего сервиса авторизации пользователей в продуктах компании.
Разрабатывать подобный модуль повторно не имеет смысла, а следовательно,
должен быть интегрирован в разрабатываемое решение. Поскольку данный
модуль не входит в непосредственное решение, то он также и не будет
рассматриваться в рамках дипломного проекта за тем лишь исключением, что
будет представлена форма авторизации, передаваемая приложению данным
модулем.
44
1.4.2 Обоснование проектных решений по программному обеспечению
Операционные системы, которые будут задействованы при разработке
решения, включают в себя следующие: Microsoft Windows 10 и Apple MacOS.
Первая служит для непосредственной разработки бизнес-логики, а вторая
для разработки интерфейса и портирования версии программы под
операционные системы семейства MacOS.
Для написания бизнес-логики информационной системы был выбран
язык программирования C# (Си-Шарп) за свое удобство на этапе разработки,
кросс-платформенность, а также присутствие механизма утилизации
невостребованной памяти. Данный язык является Объектно-Ориентированным,
что означает удобство в реализации алгоритмов программы. На момент
написания данной дипломной работы язык является достаточно быстрым, что
позитивно скажется на скорости обработки и выдачи результатов.[1]
Чтобы обеспечить максимальную заменимость используемых модулей
программы (на случай аварийной остановки одного из них) необходимо
реализовывать механизм микросервисов, что в свою очередь удовлетворяет как
требованию ООП парадигме (максимальная независимость модулей между
собой[2]) так и паттерну проектирования "Фабрика"[3].
Для обеспечения высокой скорости разработки используются
библиотеки, созданные внутри компании для собственных продуктов. Одной из
таких библиотек является библиотека сетевой связи "Erida", которая отвечает за
взаимодействие между клиентской частью приложения и центральным сервером
и между центральным сервером и другими серверами. Данная библиотека
значительно облегчает работу и за счет своей стабильности и постоянным
обновлениям исключает множество рисков, связанных с пересылкой данных
между удаленными компонентами программы.
Для отображения пользовательского интерфейса был выбран язык
гипертекстовой разметки HTML в связке с языком описания внешнего вида
CSS.[4] Данное решение позволяет создавать удобные интерфейсы, отвечающие
стандартам компании в короткий срок. Для обеспечения работы логики на
45
клиентской стороне (выдача правильно сформированных HTML страниц) будет
использоваться ASP.NET который является веб-фреймворком на языке C#.
Поскольку клиентская сторона является по своей сути веб-сервером,
отображающим сайт, то для десктоп версии клиентского приложения (от
английского desktop - настольный) необходимо использовать фреймворк-
обертку, позволяющий заключить веб-сервер и выдаваемый им сайт в единый
компонент, доступ к которому извне будет умышленно ограничен. Для этого
будет использоваться C#-Фреймворк Electron.NET, который позволяет
оборачивать .NET веб-серверные приложения.
Использование веб-сервера для разработки клиентского интерфейса
позитивным образом сказывается на дальнейшей интеграции сервиса по
предоставлению дорожной карты на сайт компании и в непосредственно другие
продукты компании.
База данных будет разработана с использованием MySQL. Преимущества
данного решения заключаются в возможности хранить огромный массив данных
(до 32 экзабайт), быструю работу. Изначальная разработка велась шведской
компанией MySQL Aktiebolag, что дополнительно может служить основанием
для утверждения о качестве данного продукта.
MySQL отлично подходит для проекта, поскольку изначально
рассчитывалась на малые и средние продукты.[5]
1.4.3 Обоснование проектных решений по техническому обеспечению
Техническое обеспечение автоматизации контроля исполнения задач по
проектам является комплексом средств, необходимых для реализации
проведения автоматизации.
Для обеспечения работоспособности программного продукта
необходимо иметь следующий набор технических средств:
1. Сервер хранения данных;
2. Сервер хранение контента;
3. Сервер обработки данных;
46
4. Пользовательская рабочая станция;
5. Локальная вычислительная сеть для передачи данных.
В данный момент компания "Норс Студиос" располагает всеми
необходимыми техническими средствами, который в полной мере
удовлетворяют требованиям технического обеспечения решения.
Так в рамках целесообразности в первое время можно использовать
сервер хранения данных и сервер хранения контента на одном физическом (или
виртуальном) сервере. В компании есть как минимум 3 физических сервера и
облачное решение от Amazon, на которых это можно реализовать. Сервер
обработки данных будет правильнее всего размещать на самом мощном сервере,
поскольку там будут происходить основные вычисления. Однако, учитывая что
в первое время не будет значительной нагрузки на программный сервер, то его
также можно разместить в уже имеющихся серверах.
Клиентскому приложению требуется персональный компьютер, при
помощи которого сотрудник будет взаимодействовать с информационной
системой.