37
№
п/п
Название
этапа
Содержание работ
Цель этапа
6
Внедрение ИС
Постепенное внедрение ИС, и
поиск недоработок системы,
в процессе правки ИС.
Эффективно
внедрить ИС.
Для обоснования своего выбора автоматизации в начале опишу все
существующие варианты стратегий.
Хаотичная автоматизация – автоматизация отдельных участков
компании, такая автоматизация позволяет автоматизировать разные
процессы компании по отдельности.
По участкам – автоматизация такого типа позволяет автоматизировать
уже не один процесс, а целую цепочку процессов.
Автоматизация по направлениям – позволяет автоматизировать целые
функциональные подразделения, деятельность которых связанна
направлением автоматизации.
Полная автоматизация – автоматизация позволяющая автоматизировать
все бизнес-процессы компании.
В данном случае будет целесообразнее использовать стратегию
автоматизации по участкам, ведь я предлагаю автоматизацию отдела
разработки программного обеспечения, такая стратегия позволит
использовать в будущем разработанную систему не только в фирме ООО
«АйСиЭл Сервисез» но и в других фирмах разрабатывающих ПО.
1.3.3 Выбор и обоснование способа приобретения ИС для
автоматизации комплекса задач
Есть несколько способов приобретения компанией информационной
системы:
Разработка (используя свои ресурсы или заказать у других
компаний).
Покупка готового ПО, соответствующего всем требованиям.
Взять за основу проект в свободном распространении и
доработать так как нужно компании.
38
Покупка готовой информационной системы не подходит по ряду
указанных в предыдущих главах причин. Таких как, стоимость продукта
велика, безопасность данных не достаточна и интерфейс программы не
удобен.
Взятие за основу другого проекта так же не подходит так как есть
вероятность ошибки в коде взятого за основу проекта и на ее устранение
уйдет огромное количество времени, так как разработчики, которые будет
дорабатывать систему не будут знать, в чем именно проблема.
Собственная разработка самый оптимальный вариант. Собственная
разработка информационной системы позволит постоянно добавлять в
систему, то, что требуется пользователям и в кротчайшие сроки. Так же это
позитивно скажется на отлове ошибок, так как разработчики смогут быстро
вычислить в чем проблема вне зависимости от того на каком уровне
произошла ошибка.
39
Глава 2. Проектная часть
2.1 Обоснование проектных решений
2.1.1 Обоснование проектных решений по информационному
обеспечению
Входными документами будут являться списки сотрудников
участвующих в проекте и их роли в нем, так же задачи и подзадачи. В списке
сотрудников будут указаны ФИО сотрудника и электронный почтовой адрес,
а также его роль в проекте. Список задач и подзадач будет содержать в себе
задачи, исполнителей и сроки.
В разрабатываемом приложении будут форма для регистрации нового
сотрудника, которая будет включать в себя поле ввода ФИО, поле пароля и
логина, а также поле ввода электронной почты. Так же в данном приложении
будет присутствовать форма создания новой задачи проекта, в ней будут
присутствовать поля ввода короткого названия задачи, ее описание и
исполнитель либо исполнители.
Данные, которые пользователи будут вводить в формы
разрабатываемого приложения будут зашифрованы с помощью протокола
HTTPS, и переданы на сервер.
Приложение, которое в дальнейшем будет разработано будет получать
данные о пользователях их роли и задачи. Для того чтобы данные были
удобно разложены и можно было запустить проект в работу в ближайшее
время, база данных будет использована не реляционная.
Не реляционная база данных подразумевает хранение данных не в виде
таблиц, а в виде объектов, хранящих в себе объекты и так по рекурсии вниз,
это позволяет держать на ней проекты котором требуется быстрый страт и
легкое манипулирование данными.
В вышеизложенной мысли было передано понимание какие данные
будут передаваться в базу данных и где будут храниться, но также ко всему
этому нужно добавить, выход данных будет реализован в виде отчетов,
составляемых автоматически приложением и что самое важное эти отчеты
40
можно получать в любое время когда пожелает менеджер проекта.
2.1.2. Обоснование проектных решений по программному
обеспечению
Веб приложение, которое будет разработано не будет зависит от вида
операционной системы так как оно будет запускаться в браузере, с одной
поправкой для Windows будет разработан также дополнительный модуль
позволяющий подключить домен, что позволит избавится от потребности
регистрироваться каждому пользователю ему бет достаточно лишь ввести
свой логин и пароль он учетной записи Windows. Логичным вопросом будет,
почему приложение будет поддерживать только одну операционную
систему, ведь в MacOS и Linux поддерживают такую же функции с учетными
записями пользователей, и это будет верно, но на данный момент мы должны
как можно быстрее выпустить приложение в работу, а компания для которой
в первую очередь оно разрабатывается использует операционную систему
Windows, что и подразумевает что в начальных версиях должна быть
реализована поддержка этой операционной системы, в дальнейшем
жизненном цикле проекта возможно будет разработаны модули поддержке
других операционных систем.
Для обработки данных пользователей и хранения нужно использовать
сервер с установленной на нем операционной системой Linux, эта
операционная система была выбрана потому как она не перегружена
ненужными нам модулями в отличии от MacOS и Windows, в которых
встроено множество всего полезного для пользователя но как операционные
системы для серверов они не подходят.
Процесс разработки будет проходить на операционной системе
Windows так как она используется компанией разработчиком, а также уже
имеет множество программных продуктов, обеспечивающих удобную и
быструю разработку программного обеспечения. Одним из таких
приложений для разработки является Visual studio code, она хороша тем, что
под нее написанной множество дополнительных пакетов для разработки на
41
разных языках что позволит работать в ней как разработчикам части
приложения, которою видит пользователь так и серверную часть.
На данное время не один проект не обходится без системы контроля
версий, такая система позволит контролировать версии разработки и в
момент, когда будет допущена ошибка будет возможность вернутся к
прошлой версии проекта и методом сравнения найти ошибки, допущенные в
новой версии проекта.
На данный момент существует множество СУБД для не реляционных
баз данных таких как MongoDB, Azure Cosmos DB, Cassandra и еще
множество других СУБД.
MongoDB, данная СУБД позволяет бесплатно и быстро развернуть базу
данных на их серверах, также обеспечивает отличную скорость подключения
и уровень защищенности данных пользователей, но для нужд компании ее
можно изменить и усовершенствовать.
Azure Cosmos DB данная СУБД была разработанная Microsoft, она
отлично подойдет компаниям которые собираются разрабатывать множество
приложений для работы с большим объемом данных и показывает высокую
производительность. Но данная СУБД довольно дорого обойдется компании
если мы захотим ее использовать в разработке.
Cassandra, СУБД обладает такими преимуществами как высокой
скоростью доступности, восстановление данных на ходу, не имеет
центральной точки отказа, строка может динамически расширяться до 2
миллиардов колонок, резервное копирование не нужно.
В результате проведенного анализа было принято использовать
MongoDB так как эта СУБД бесплатна, отказа устойчива, с хорошим уровнем
защиты.
Для разработки данного проекта есть несколько подходящих языков
программирования такие, как python, JS, php.
Python, на данном языке уже написано множество проектов, он
обладает динамической типизацией и отличной скоростью работы с
42
данными. Данный язык отлично подошел бы и для описываемого мною
проекта, но, к сожалению, он обладает очень низкой скоростью работы по
сравнению с JS и php.
Php давно используемый язык программирования многими
разработчиками. Последняя вышедшая версия языка, обладает хорошими
показателями скорости, но данный язык обладает минусом в виде отсутствия
защиты от Sql инъекций.
JS прекрасный быстро развивающийся язык программирования, для
которого был написан фреймворк NodeJS данный фреймворк будет
использоваться в представленной мною разработке так как, скорость его
работы выше всех выше представленных языков. И он защищен от Sql
инъекций.
2.1.3 Обоснование проектных решений по техническому
обеспечению
Техническое обеспечение – это обеспечение техникой способной
удовлетворить потребности разрабатываемого проекта.
Для грядущего проекта потребуется техника для возможно новых
сотрудников, которые прейдут в компанию для работы над проектом, так же
сервер, на котором будет размещено разрабатываемое программное
обеспечение.
Техника для новых сотрудников. Закупка техники не требуется так как
после выхода срока гарантии ноутбуки меняются на новые у постоянных
сотрудников, компания выделит последнюю снятую с обихода версию
ноутбуков новым сотрудникам, пришедшим для разработки проекта, в
дальнейшем если появится потребность в новой технике для разработки
будет закуплена партия новых ноутбуков del latitude 7280. Именно эти
ноутбуки были выбраны так как их легко носить с собой, у них отличная
производительность, которой будет с полна достаточно для разработки, а
также удобная клавиатура для быстрой печати.
Сервер. На начальной стадии разработки проекта сервер не требуется, в
43
связи с тем, что на балансе компании имеется уже неиспользуемый сервер
прошлого поколения, которого для первоначального запуска и тестирования
программного обеспечения, разрабатываемого компанией, будет достаточно.
Если же в дальнейшем он не оправдает ожидания либо его мощности не
будет хватать, главе потребуется заполнить запрос на покупку нового сервера
со списком нужных ему характеристик, так же ему нужно будет обосновать
причину закупки.
2.2 Разработка проекта автоматизации
2.2.1 Этапы жизненного цикла проекта автоматизации
Для реализации проекта я буду использовать жизненный цикл
стандарта RUP. Стандарт RUP подразумевает разработку, проходящую по
фазам столько раз сколько нужно проекту, каждую фазу можно разбить на
этапы, в конце каждой фазы выпускается версия для использования.
Для рассматриваемого проекта RUP стандарт с итерационной моделью
подходит лучше всего. Выбранный мною стандарт позволяет на каждом из
этапов выводить готовую версию продукта таким образом первую версию
продукта можно будет выпустить в работу, в наикротчайшие сроки. Проект
стримится как можно быстрее выйти в свет, а значит, что нам нужно в
ближайшее время добиться результата в виде работающего приложения с
минимальным функционалом. RUP стандарт дает нам возможность на первой
фазе развернуть минимальный функционал на серверной части и на видимой
пользователю, а на дальнейших фазах уже последовательно добавлять
функционал которой уже был в требованиях а так же тот который в них не
входил.
Методология RUP имеет жизненный цикл, разбитый на четыре фазы,
начало проекта, уточнение, построение, внедрение. Первая фаза
предполагает рассмотрение проекта, понимание его важности и есть в нем
вообще нужда. Фаза уточнения предполагает анализ требований к разработке
и ее архитектуры, устранение рисков. Фаза построения, это фаза разработки,
на данной фазе все силы команды должны быть сосредоточенны на
44
разработке. Внедрение фаза, когда проект выходит в работу, в ходе данной
фазы будут отловлены баги и исправлены.
На основании выбранной мною модели я составил начальные этапы
проекта:
1. Серверная часть с подключенной базой данных.
2. Пользовательский интерфейс, связанный с серверной частью.
3. Основной функционал приложения для возможности управления
проектом по модели Scrum.
4. Возможность подключения активной директории Windows.
5. Разворачивание приложения на сервере компании.
Первый этап «Серверная часть с подключенной базой данных» в ходе
этого этапа должен быть разработан основной объем серверной части, а
также подключена база данных. В результате работы над первым этапом
должно получиться приложение без графического интерфейса имеющее
возможность записывать и считывать данные из базы данных, а также их
обрабатывать.
Второй этап «Пользовательский интерфейс, связанный с серверной
частью» на данной фазе, предстоит полностью разработать графический
интерфейс приложения, а также научить серверную часть и графический
интерфейс работать в месте.
Третий этап «Основной функционал приложения для возможности
управления проектом по модели Scrum» этот этап самый объемный и
длинный по продолжительности. В ходе третьего этапа нужно написать
блоки как для пользовательского интерфейса, так и для серверной части. В
приложение должна быть добавлена возможность работы учетных записей,
добавление задач на конкретного пользователя, а также настроены права
пользователей. На выходе из этапа мы получим полноценно работающее
приложение, обеспечивающее функционалом позволяющим управлять
проектом по модели Scrum.
Четвертый этап «Возможность подключения активной директории
45
Windows» должна привнести функционал позволяющий импортировать
пользовательские учетные записи из домена компании.
Пятый этап «Разворачивание приложения на сервере компании»
завершающий этап начальной разработки. Предстоит настроить сервер,
установленный в компании, залить туда приложение, заказать у провайдера
статический IP адрес, после проделки всех настроек и установок нужно
провести тестирование на стабильность и стрессоустойчивость. На момент
завершения стадии пять компания получит веб приложение для управления
проектами с помощью scrum модели.
Дальнейшая разработка будет вестись в направлении увеличения
функционала, улучшении старого, а также правка багов и т. д.
После разработки начальных пяти этапов проекта, проект перейдет в
стадию эксплуатации на локальном уровне. В начале было решено сделать
локальное внедрение для того, чтобы отловить основную часть упущений, в
ходе разработки, уже на первых парах использования. По всем
вышеизложенным критериям, для этой разработки больше всего подходит
метод внедрения скачек.
После прохождения нескольких месяцев со дня внедрения и ввода в
эксплуатацию, после исправления всех недочетов проект станет доступен и
для других компаний, в которых требуется такая система.
Стратегия внедрения скачек позволит добиться максимального
качества приложения за минимальное время, но при больших рисках. Не
выходя на рынок, как только было написано приложение, сохранит
репутацию фирмы, ведь если приложение выйдет с огромным количеством
недоработок, потом его уже никто не купит.
2.2.2. Характеристика нормативно-справочной, входной и
оперативной информации
Так как в моей дипломной работе рассматривается разработка
серверной части приложения автоматизации, то далее будет рассмотрена
работа с данными только на серверной части.
46
Так как в моем проекте используется не реляционная база данных, а
именно MongoDb то для начала нужно пояснить как в ней хранятся данные.
В базах данных такого типа данные хранятся в виде объектов.
В объект user_moddel – будут записываться данные пользователей, в
поле id должном быть сгенерирован случайным образом уникальный ключ, в
name будет передаваться никнейм сотрудника, поле password отвечать за
хранение пароля пользователя, mail хранит электронный адрес пользователя.
Стоит заметить, что в дальнейшем будет написана функция автоматической
генерации аканта получая данные из Active Directory организации.
В объект project_model – будут записываться данные о проекте. В поле
id будет генерироваться уникальный код, в поле name имя проекта. В поле
scrum_master будет храниться id скрам-мастера, руководящего проектом,
product_owner хранит id владельца проекта. Поле team в полной степени
показывает прелесть не реляционной базы данных ведь в одном поле я могу
хранить множество значений, в этом поле будут записаны все id
пользователей, которые входят в команду разработки проекта.
Объект task должен получать данные о задачах, task хранит в себе такие
поля как: id_project сюда передается id проекта который создал скрам-мастер
либо владелец проекта, id это уникальный ключ задачи, name короткое
название задачи, description подробное на сколько это возможно описание
задачи, stage_of_development является объектом хранящим внутри два поля
stage передающий прогресс задачи и coment хранящий в себе комментарий
по прогрессу задачи, комментариев может быть множество. Acting хранит в
себе id исполнителей задачи.
Все вышеприведенные структуры данных заполняются только после
обработки на валидность данных пришедших с пользовательского
интерфейса. После заполнения объект отправляется в базу данных и хранится
там, после можно будет получить из базы данных эти данные и отправить
при запросе в пользовательский интерфейс.
Таким образом получив все задачи, описанные в техническом задании,