37
1.4 Обоснование проектных решений
1.4.1 Обоснование проектных решений по информационному
обеспечению
Основным требованием к реализации проекта интеграции являлась
возможность реализации и существования такого программного продукта,
который бы соответствовал выше описанным требованиям в существую-
щих реалиях. Задачей было выявить и принять оптимальный вариант им-
пелементации проекта в реалиях бизнеса, компании и команды разработки.
Вопрос о необходимости реализации собственного програмного ре-
шения возникал только на начальных стадиях, когда ещё не были определе-
ны возможные пути реализации в соответствии со строгими требованиями.
Однако проведённый анализ позволяет утверждать в возможности
существования такой реализации проекта, что будет полностью соответ-
ствовать предъявленным требованиям. А все вопросы касаемые необхо-
димости собственной реализации отпали в ходе сравнительного анализа.
Ввиду несоответствия имеющихся(готовых) програмных решений постав-
ленным требованиям единственным возможным выходом из ситуации
видится разработка нового програмного решения с нуля.
1.4.2 Обоснование проектных решений по программному обеспе-
чению
Как описано в аналитической части, решено было создать новый
программный продукт на высокоуровневом языке программирования Go.
Его основными достоинствами являются:
38
– Лаконичный синтаксис. Как утверждают разработчики язык можно
освоить за пару недель, а его спецификация[10] умещается менее,
чем на сотне страниц, против четырёх с половиной тысяч для C++;
– Исходный код программы компилируется в статический исполняе-
мый фаил. Это даёт высокую производительность для программ на-
писанных на этом языке. Не такую высокую, как у Clang или C++, но
в десять раз превосходящую производительность интерпретируемых
скриптовых языков;
– Поддержка на уровне языка многопоточного и многопроцессорного
программирования. Встроенные в язык специальные структуры дан-
ных, как каналы и горутины;
– Низкое потребление ресурсов из-за компиляции исходного кода в ма-
шинный код конкретной платформы, без дополнительных прослоек
в виде виртуальных машин (Java, C#, Python);
– Ниша языка, для которой он и проектировался — написание неболь-
ших асинхронных высокопроизводительных сетевых программ.
Всё описанное выше, делает Golang идеальным кандидатом для
решения поставленной задачи.
1.4.3 Обоснование проектных решений по техническому обеспече-
нию
Одним из технических требований к проекту – это его экономическая
рентабельность. Так как проект представляет из себя оптимизацию и
сокращение статьи расходов компании на поддержание инфраструктуры
фильтрации нежелательной корреспонденции, на многие и многие года
вперёд. То и чем меньше компании потребуется человеческих и техни-
ческих средств на поддержание новой инфраструктуры, тем и выгоднее
будет проект. По данному критерию многие технологии, такие как Java и
39
C# были откинуты ещё до проведения сравнительного анализа, ввиду того,
что их виртуальные машины очень требовательны к ресурсам. А такие
технологии как С и С++ очень требовательны к процессу разработки и
реализация проектов на них по времени была бы не менее затратна, чем
поддержка на Java.
К счастью, удалось подобрать решение, которое бы подходило по
обоим требованиям, как скорость разработки, так и низкие требования к
ресурсам. По итогам тестирования прототипа на Go было установлено,
что для поддержки текущей нагрузки потребуется один единственный
экземпляр виртуальной машины на датацентр всего с 1 ядром CPU и 1Gb
ОЗУ (c запасом). Что для текущих реалий большой IT-компании совершен-
ный пустяк. Более подробно результаты нагрузочных тестов приведены во
второй части.
40
2 ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
ЖЦИС - это период создания и использования ИС, начиная с момен-
та возникновения потребности в ИС и заканчивая моментом полного ее
выхода из эксплуатации.
Стадии жизненного цикла информационной системы:
1. Предпроектное обследование:
– сбор материалов для проектирования, при этом выделяют фор-
мулирование требований, с изучения объекта автоматизации,
даются предварительные выводы предпроектного варианта
ИС;
– анализ материалов и разработка документации, обязательно
даётся технико экономическое обоснование с техническим за-
данием на проектирование ИС.
2. Проектирование:
2..1. предварительное проектирование;
– выбор проектных решений по аспектам разработки ИС;
– описание реальных компонент ИС;
– оформление и утверждение технического проекта (ТП).
2..2. детальное проектирование:
– выбор или разработка математических методов или ал-
горитмов программ;
– корректировка структур БД;
41
– создание документации на доставку и установку про-
граммных продуктов;
– выбор комплекса технических средств с документацией
на ею установку.
2..3. разработка техно-рабочего проекта ИС (ТРП).
2..4. разработка методологии реализации функций управления с по-
мощью ИС и описанием регламента действий аппарата управ-
ления.
3. Разработка ИС:
– получение и установка технических и программных средств;
– тестирование и доводка программного комплекса;
– разработка инструкций по эксплуатации программно-
технических средств.
4. Ввод ИС в эксплуатацию:
– ввод технических средств;
– ввод программных средств;
– обучение и сертификация персонала;
– опытная эксплуатация;
– сдача и подписание актов приемки-сдачи работ.
5. Эксплуатация ИС:
– повседневная эксплуатация;
– общее сопровождение всего проекта.
Модели жизненного цикла информационной системы:
– Каскадная модель - предлагает переход на следующие этапы после
полного осуществления работ по предыдущему этапу. Модель де-
монстрирует классический подход в любых прикладных областях;
– Итерационная модель - поэтапная модель с промежуточным кон-
тролем и циклами обратной связи. Преимущество данной модели -
42
поэтапные корректировки, которые обеспечивают меньшую трудо-
емкость по сравнению с каскадной. Однако время жизни каждого из
этапов рассчитывается на весь период разработки;
– Спиральная модель - данная модель делает упор на начальные этапы
анализа и проектирования. Эта модель представляет собой итераци-
онный процесс разработки, где каждая итерация (цикл), представ-
ляет собой законченный цикл разработки, приводящий к выпуску
версии изделия (версии проекта ИС), который совершенствуется
от итерации к итерации, чтобы стать значимой информационной
системой. При этом каждый виток спирали соответствует поэтап-
ной модели создания информационной системы. Т.о. углубляется и
последовательно конкретизируется обоснованный вариант ИС, кото-
рый и доводится впоследствии до реализации.
В компании Интермедия распространены и поддерживаются совре-
менные гибкие подходы к разработке программного обеспечения на базе
Agile Manifesto[12] основными принципами[13] которого является:
– Люди и взаимодействие важнее процессов и инструментов;
– Работающий продукт важнее исчерпывающей документации;
– Сотрудничество с заказчиком важнее согласования условий контрак-
та;
– Готовность к изменениям важнее следования первоначальному пла-
ну;
В команде EmailSequrity используют спиральную модель на базе
метода управления проектами Scrum[6] с двух недельными итерациями –
спринтами.
SCRUM – набор принципов, ценностей, политик, ритуалов, арте-
фактов, основанных на скрайбинге и скрапбукинге, на которых строится
процесс SCRUM-разработки, позволяющий в жестко фиксированные и
43
небольшие по времени итерации, называемые спринтами (sprints), предо-
ставлять конечному пользователю работающий продукт с новыми бизнес-
возможностями, для которых определён наибольший приоритет.
Спринт – итерация в скраме, в ходе которой создаётся инкремент
бизнес-продукта. Жёстко фиксирован по времени. Длительность одного
спринта от 1 до 4 недель. Чем короче спринт, тем более гибким является
процесс разработки, релизы выходят чаще, быстрее поступают отзывы от
потребителя, меньше времени тратится на работу в неправильном направ-
лении. С другой стороны, при более длительных спринтах скрам-команда
уменьшает издержки на совещания, демонстрации продукта и т. п.
SCRUM, Kanban, как самые известные гибкие методологии ста-
ли стандартом де-факто при разработке программных продуктов любой
сложности. В общем и целом их можно отнести к Спиральной модели
жизненного цикла.
Весь процесс подготовки и реализации проекта интеграции был раз-
бит на 4е двух недельных спринта, или итерации. По окончании каждого из
них необходимо было получить завершённый продукт, будь то программ-
ное обеспечение или документация, пользовательская или проектная. На
основании чего корректировались, изменялись или отбрасывались даль-
нейшие планы.
Основной целью первого спринта было – провести исследование
возможности реализации проекта интеграции в соответствии с предъяв-
ленными требованиями. По итогу необходимо было получить проектную
документацию, описывающую весь процесс исследования и резюмирую-
щую итог.
Второй спринт отведён на подготовку проекта и создание MVP. По
результатам тестирования MVP на демонстрации стало чётко понятно, что
выдвинутые предположения о необходимости, экономической рентабель-
ности и инструментах реализации проекта, подтверждаются. Итогом вто-
44
рого спринта стало решение о необходимости создания нового продукта с
требуемым функционалом.
Третий спринт, существование которого определялось итогами
предыдущих спритов, представлял из себя набор чётких задач по реали-
зации необходимого функционала:
а) UDP-сервер для получения лог-сообщений;
б) Фильтр входящих лог-сообщений;
в) Парсер входящих лог-сообщений;
г) Обработчик и валидатор входящих лог-сообщений;
д) Форматтер и отправитель исходящих сообщений для партнёра;
Результатами работы пятой и шестой недель стал практически готовый
программный продукт поддерживающий весь требуемый функционал.
В задачи четвёртого и последнего спринта входило – подготовка
пользовательской и проектной документации для внедрения полученно-
го на предыдущем этапе программного решения. Компания Инермедия
большая, и с целью оптимизации рабочих ресурсов процессы связанные с
разработкой и внедрением разделены между разными отделами компании.
Подготовкой инфраструктуры и внедрением нового решения занимается
команда системных администраторов компании. Чтобы команде систем-
ных администраторов было понятно что за продукт они внедряют, какие к
нему требования, как его мониторить и как разворачивать – необходимо
было подготовить полную и исчерпывающую документацию, включаю-
щую нагрузочное тестирование. По завершении спринта для команды
системных администраторов и менеджеров компании Интремедия была
проведена демонстрация полученного результата.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
45
В ходе жизненного цикла информационной системы всегда могут
возникнуть риски, могущие сорвать разработку. Для их избежания прово-
дится оценка вероятных рисков и разрабатываются способы, позволяющие
избежать эти риски или минимизировать их влияние.
Рассмотрим наиболее вероятные риски по фазам жизненного цикла
информационной системы.
Фаза исследования концепции.
На фазе исследования концепции возможен риск сознания концеп-
ции, которую впоследствии будет сложно (не возможно) реализовать. На-
пример при отсутствии возможности передачи анонимной информации
пользователей почтовых услуг компании Интермедия. Или не возможно-
сти создания имеющимися средствами продукта, что будет удовлетворять
требованиям по производительности и потреблению ресурсов в поддержке
или разработке.
Для предотвращения возникновения рисков на фазе исследования
концепции, необходимо чётко понимать свои возможности. Для предот-
вращения переоценки собственных сил, в первую очередь нужно создать
общую концепцию, в которой будут включены только базовые функции
будущей системы. И по мере углубления в тему разработки расширять
дополнительными функциями.
Фаза планирования.
На фазе планирования возможен риск неправильного планирования,
разработка очень оптимистичных планов проекта, в которые не возможно
уложиться имеющимися ресурсами разработки, вследствие чего придётся
увеличивать время разработки, что повлечёт за собой удорожание проекта
в целом. Как например, для соответствия требованию по производитель-
ности решения, изначально планировалось создавать программный про-
46
дукт на С или С++. Вполне вероятно, что требуемый результат не был
бы получен во вменяемые сроки. К фазе планирования нужно отнестись
очень важно, следить за каждым этапом и анализировать реалистичность
результатов.
Для предотвращения риска на фазе планирования, нужно во вре-
мя планирования заложить в график поправки на возможные задержки
в выполнении тех или иных действий. Так нужно попытаться создать
гибкий график который бы не ломался в связи задержки или опережения.
Учитывая, что присутствовал дополнительный риск связанный с использо-
ванием новой, до этого не использованной и не тестированной командой,
технологии.
Фаза разработки.
На фазе разработки возможен риск того, что разработка определён-
ного модуля будет сопряжёна с большими трудностями, или что какая-та
функция будет мешать продвижению разработки. На данной фазе важно
вовремя определить проблемный модуль или функцию, и по возможности
упростить её, заменить другой, или убрать из проекта полностью.
Для предотвращения риска разработки сложного модуля, можно
принять несколько решений, либо разбить данный модуль на несколько
и решить поставленные задачи по отдельности, либо упростить сложный
модуль, если это единственный вариант преодоления риска. В процессе
разработки и промежуточных нагрузочных испытаний встретились с не
предвиденной ранее проблемой, связанной со сложностью маштабирова-
ния будущей системы на возможность использования TCP и UDP одно-
временно. Было решено отказаться от данного функционала и оставить
возможность использовать только один способ.
Фаза приёмочного тестирования.