Проект автоматического управления услугами в телефонной сети общего пользования

Меня тут регулярно спрашивают, как зарабатывать деньги на свободном программном обеспечении. Один из возможных способов — участвовать в тендерах и их выигрывать. А для того, чтобы выигрывать тендеры, надо писать технические и ценовые предложения. Наш (Дениса, Виктора и мой) пример подобной документации я хочу Вам сегодня показать. Можно использовать этот текст, как образец, чтобы поучаствовать в каком-нибудь ещё тендере по теме.

1. Техническое предложение по лоту №21 «Услуги по автоматизации шагов активация/деактивация услуг ТфОП в сквозных бизнес-процессах операционной деятельности филиалов (пилотный проект)»

Проект «Автоматизация шагов активация/деактивация услуг ТфОП в сквозных бизнес-процессах операционной деятельности филиалов (пилотный проект)» согласно документации, задания и исходных данных, полученных от заказчика, может быть реализован с использованием собственной разработки нашей компании, интегрированной с решениями сторонних производителей программного обеспечения (ПО) на базе открытых стандартов, оборудования IBM и текущими решениями, внедрёнными в АО «Казахтелеком». Наш опыт позволяет построить наиболее экономичное решение без ущемления надёжности и масштабируемости системы.

Каждый элемент архитектурного решения, предлагаемого нами, имеет свои преимущества. Серверные продукты Apache надёжны и соответствуют стандартам, и при этом являются свободным ПО, позволяющим использовать национальные компании для развития и поддержки системы без ущемления их интересов. Оборудование IBM позволяет эффективно и недорого строить небольшие отказоустойчивые системы. Открытые стандарты в области управления бизнес-процессами и интеграции позволяют гибко добавлять/удалять компоненты, сочетая их в единой системе. Собственные решения компании интегрируют разнообразное телекоммуникационное оборудование в единую информационную среду.

2. Программная часть ядра системы

Для достижения необходимой модульности используется стандартная модель промышленной архитектуры, разработанной для языка программирования Java (J2EE). Это позволяет добавлять новую функциональность, такую как новые отчеты, новые АТС и новые виды АТС, тем самым облегчая дальнейшее развитие проекта. Данная модель привлекательна еще и потому, что позволяет строить слабосвязанные системы, отличается широким инструментарием для разработчика и широким кругом дополнительных модулей с открытым исходным кодом.

2.1 Хранилище данных

Базы данных (БД) MySQL служат для хранения журнальной и конфигурационной информации, а также для построения статистических выборок. Отдельные БД реплицируются с использованием двусторонней репликации (multi-master) и отправляют данные для записи на ленту. Помимо отказоустойчивости выбор MySql обусловлен следующими факторами:

• естественная интеграция с технологиями доступа к данным J2EE: Spring JDBC Template и Hibernate;
• высокое качество документации и наличие средств разработки;
• лицензионная политика, позволяющая осуществлять поддержку и развитие систем и не зависящая от монополии крупных производителей ПО.

2.2 Серверы Web-services — Apache Axis2

В качестве сервера Web-services предлагается использовать Apache Axis2. Данная платформа поддерживает широкий круг спецификаций SOAP 1.1/1.2, MTOM, XOP, SOAP with Attachments, WSDL 1.1, WS-Addressing, WS-Policy, SAAJ 1.1, необходимых для построения гибкой распределенной слабосвязанной системы. Предполагается, что каждый модуль (адаптер АТС) будет представлен на нескольких логических слоях: как сервис, управляемый объект, приложение, активируемое с помощью сообщений (message driven).

2.3 Сервер JMS — Apache ActiveMQ

В качестве транспортного сервера для сообщений предлагается использовать Apache ActiveMQ. Данное ПО выпускается под лицензией, позволяющей использовать его в промышленных системах. Данный продукт поддерживает широкий круг стандартов. Данный сервер сообщений легко интегрируется с Apache Axis2.

2.4 Web-сервер — Apache Tomcat

В качестве основного средства управления системой предлагается использовать web-интерфейс. Для его функционирования необходим HTTP сервер/сервлет контейнер. В этом качестве предлагается использовать широко известный HTTP сервер — Apache Tomcat.

2.5 Виртуальная машина — VMware ESX

Выбор в качестве основы решения платформы J2EE для прикладного обеспечения и написанной на Java аппаратно независимой базы данных позволит устанавливать систему без перепрограммирования на широкий набор аппаратных средств. Полный набор серверного ПО представляет собой образ операционной системы с предустановленным ПО — сервером приложений, базой данных, транспортом передачи сообщений JMS и др. Данный образ устанавливается на хипервайзер VMware ESX или аналогичный с возможностью удалённого доступа к системе. На хипервайзере работает операционная система Red Hat Linux или аналогичная. Кроме образа системы также необходимо создать конфигурационный файл, необходимый для описания взаимодействия с другими серверами, настройки репликации данных и содержащий другие индивидуальные настройки. Для того чтобы установить дополнительный сервер, достаточно установить на него VMware ESX и перенести на него виртуальный образ, исправить конфигурационный файл и реплицировать данные.

2.6 Управление системой — JMX

Для управления системой предполагается оснастить все модули средствами управления JMX. Предлагается использовать Spring JMX Annotations, что позволит повысить прозрачность бизнес-логики за счет того, что она не отягощена кодом к ней не относящимся к инфраструктурным.

3. Аппаратная платформа для работы ядра системы

Согласно требованиям, обозначенным в задании, не определено и требует дополнительного согласования с заказчиком, требуется ли поставить или использовать имеющееся оборудование. После проведения аудита список оборудования может быть уточнён. В случае поставки исполнитель исходит из следующего списка, позволяющего построить отказоустойчивую систему.

Аппаратный комплекс, достаточный для работы ядра системы, реализуется на оборудовании компании IBM. На площадках Заказчика устанавливаются: 2 сервера IBM System x3650 Express; 1 система хранения данных IBM System Storage TS2340 Tape Drive, и необходимые расходные материалы.

Сервер IBM System x3650 Express высотой 2U имеет до двух четырехъядерных процессоров Intel Xeon X5405. Сервер обладает высокой производительностью и готовностью, что важно для ресурсоемких приложений. Сервер имеет следующие характеристики:

• 2 ГБ высокопроизводительной памяти нового поколения (масштабируется до 48 ГБ);
• четыре разъема PCI-Express x8. Возможность установки двух PCI-X с частотой 133 МГц;
• до шести 3,5-дюймовых жестких дисков SAS или SATA или до восьми 2,5-дюймовых дисков SAS;
• возможность использования внутренних ленточных накопителей для резервного копирования данных;
• интегрированный RAID-0, -1 и -10 с возможностью модернизации до RAID-5 с помощью IBM ServeRAID-8k без необходимости использования разъемов PCI;
• «горячая замена» вентиляторов, блоков питания и жестких дисков.

Система хранения на магнитной ленте на базе ленточного накопителя IBM System Storage TS2340 Tape Drive Express предназначена для резервного хранения и архивирования всех данных об активации/деактивации услуг за последние 6 месяцев. IBM System Storage TS2340 обеспечивает возможность хранения до 1,6 ТБ (с учетом сжатия 2:1) на одном картридже. Также поддерживается возможность удаленного хранения картриджей для восстановления данных на резервных площадках. Накопитель имеет следующие характеристики:

• внешний ленточный накопитель с интерфейсом SAS 3 Гбит/c;
• запись данных на картриджи LTO4 емкостью 800 ГБ без сжатия;
• поддержка совместимости с картриджами LTO предыдущих поколений;
• скорость чтения/записи данных — до 120 МБ/с без сжатия.

4. Логическая архитектура системы

Система построена по модели стандартной для сервисно-ориентированной архитектуры (СОА) трёхуровневой архитектуре деятельности, в которой общая интеграционная шина используется как для подключения новых технологических модулей, рабочих мест и служб, так и для аналитических выборок и интеграции с другими системами.

5. Реализация функциональных требований

5.1 Создание единой корпоративной информационной системы

При создании единой корпоративной информационной системы в области управления телефонными подключениями необходимо учитывать следующие принципы.

• Корпоративная информационная система должна обеспечивать безотказную работу 24/7. Сбой отдельных частей системы не должен нарушать работу системы в целом.
• В связи с высокой конкуренцией в области предоставления услуг система должна позволять изменять бизнес-логику процессов без ущерба для надёжности системы, быть гибкой и легко масштабируемой.
• Высокий уровень управляемости системы необходим для сокращения эксплуатационных затрат и минимизации эксплуатационных рисков. Для этого необходимо предоставить удобные средства аналитики, мониторинга и администрирования.
• По возможности, необходимо исключить жёсткую привязку системы к конкретному технологическому решению или инфраструктурному комплексу, подрядчику, производителю. Для этого необходимо широко использовать открытые стандарты, стандарты, построенные на сетевом взаимодействии, веб-интерфейсы и модульную архитектуру.

На общем уровне подобные цели достигаются использованием типовых решений, основанных на принципах сервисно-ориентированной архитектуры. В каждом конкретном случае перед прописыванием компонентов архитектуры и их взаимодействия, а также планов по разработке новых, интеграции и модернизации существующих компонентов необходимо руководствоваться результатами аудита информационной системы, чтобы потратить выделенные средства с максимальной отдачей.

5.2 Взаимодействие с типовыми АТС

Реализация интерфейсов между системой и цифровыми АТС заказчика будет обеспечиваться специальными компонентами, позволяющими преобразовывать поступившие от ядра системы команды в оригинальный синтаксис соответствующих АТС, передавать эти команды и осуществлять обратное преобразование результатов выполнения команды от АТС.

Пример:
для взаимодействия с коммутационной станцией Alcatel S12 ядра системы будут преобразовываться в соответствующие MMC команды MODIFY-RELATION, либо MODIFY-SINGLE-SUBSCRIBER, либо в макросы, позволяющие напрямую обрабатывать большие массивы данных в памяти модулей и на дисках. Выбор способов взаимодействия с учетом требуемой безопасности и быстродействия будет согласовываться на этапе обсуждения ТЗ.

В качестве типовых АТС будут рассматриваться имеющиеся в наличии и доступные для тестирования АТС в предполагаемой пилотной зоне. Согласование и анализ детального ТЗ, включающего список оборудования в тестовой зоне, должны происходить в период 3-4 недели реализации проекта. В течении этого периода АО «Казахтелеком» должен будет утвердить список интегрируемого с системой оборудования, предоставить стандартизованные документы, описывающие протоколы обмена рабочих мест оператора с соответствующими АТС, подготовить и выделить тестовое оборудование.

Кроме того, наша компания, являясь официальным партнером большинства крупных производителей телекоммуникационного оборудования (Alcatel-Lucent, NSN, Huaway, Ericson), будет использовать собственные данные об архитектуре и интерфейсах стандартизованных АТС.

5.3 Автоматизация процесса активации/деактивации услуг

Заданные в едином графическом интерфейсе команды на обработку абонентов будут анализироваться ядром и, в соответствии с анализом БД, преобразовываться в соответствующие обращения к одной или нескольким АТС. При этом «работа» системы с АТС разных типов останется за кадром для конечного пользователя. Ввод/вывод информации будет стандартизован.

Для автоматизации процесса активации/деактивации услуг необходимо выявить все источники информации о том, что та или иная услуга должна быть активирована/деактивирована. Источниками информации могут быть внутренние системы заказчика, таймеры внутри системы, клиенты заказчика и операторы заказчика.

Ниже перечислены события, при которых происходит активация/деактивация услуг:

• клиент в голосовом меню в тоновом режиме выбирает, какую услугу активировать/деактивировать;
• клиент активирует/деактивирует услугу (АОН «CLIP», анти-АОН «CLIR», прямая горячая линия, переадресация звонков, уведомление о поступлении нового вызова, побудка «Будильник», конференц-связь, переадресация на автоинформатор, сообщение «Просьба не беспокоить», сообщение «Номер временно не может быть вызван», наведение справки во время разговора, обслуживание с ограничением) с помощью звонка в колл-центр заказчика или через веб-интерфейс;
• заказчик устанавливает таймеры на те или иные услуги для определенных клиентов. При наступлении указанной даты происходит автоматическая активация/деактивация услуг;
• система биллинга заказчика присылает запрос на активацию/деактивацию услуг в случае событий на счете клиента;
• в исключительных случаях оператор системы может вручную посредством web-интерфейса сформировать заявку на активацию/деактивацию услуг для определенных клиентов.

Дополнительно заказчик может сформулировать алгоритмы автоматической активации/деактивации услуг. Уточнённый список услуг будет создан по результатам аудита.

5.4 Планирование и распределение нагрузки в процессе активации/деактивации услуг

Немедленное исполнение команд по модификации больших массивов абонентов может быть не всегда разумным, а в некоторых случаях — даже привести к сбоям в работе коммутационной станции. Для снижения подобных рисков будут применяться алгоритмы анализа текущей нагрузки на коммутационные станции, и, в случае, если немедленное исполнение команды будет нести риск потенциальных сбоев, пользователю будет предлагаться отложить исполнение команды на ночное время (час наименьшей нагрузки), когда соответствующая модификация будет более безопасна.

5.5 Прогноз снижения нагрузки на технический персонал

Согласно общей статистике, примерно 80% команд, подаваемых инженерами на коммутационных станциях, — команды по модификации БД. Кроме того, прежде чем попасть к инженерам на конечную станцию в виде разнарядки, указания по модификации абонентов (активация, деактивация, подключение ДВО и т.д.) обрабатываются и другими сотрудниками оператора. Использование предлагаемой системы не только сократит нагрузку на таких сотрудников, но и значительно ускорит выполнение заявок клиентов.

5.6 Расширение списка обслуживаемых компонентов сети

Для добавления новой АТС поддерживаемого типа необходимо инициировать web-сервис, привязанный к этой АТС. После регистрации этого web-сервиса в системе новая АТС будет немедленно готова к работе. Для того чтобы включить в систему новый тип АТС, необходимо написать адаптер, который удовлетворяет единому интерфейсу взаимодействия адаптеров с ядром системы. Поскольку предлагаемая система является слабосвязанной, то подключение/отключение АТС происходит на лету без остановки системы. В особо сложных случаях при подключении оборудования с полностью новыми свойствами возможна доработка системы вне рамок данного технического предложения.

5.7 Интеграция с внешними информационными системами

Интерфейс к внешним системам строится на технологии WSDL, другими словами, необходимые данные для обмена с внешними системами описываются на формальном языке. Внешние системы получают доступ к данным, используя стандартный брокер сетевых услуг.

Интеграция с внешними системами включает в себя, но не ограничивается, следующими взаимодействиями:

• взаимодействие с АСР БиТТЛ для оценивания объёма и типа получаемых абонентом услуг;
• взаимодействие с CRM системой для адресной работы с индивидуальными и коллективными абонентами;
• взаимодействие с системой автоматизации Первичного технического учета Smallworld для сообщения возможных аварийных состояний АТС.

5.8 Спецификация единого интерфейса взаимодействия между системой и оборудованием

Единый интерфейс взаимодействия системы и оборудования построен по иерархической схеме. Поскольку все АТС имеют разную функциональность, то корневым интерфейсом будет тот, который содержит пересечение функциональности различных АТС, т. е. те функции, которые может выполнять любая АТС.

Интерфейс предполагает 3 группы элементов:

• методы — осуществляют те или иные операции на АТС, включая активацию/деактивацию услуг, проверку состояния клиентского подключения;
• поля — содержат буквенно-числовую информацию о состоянии АТС, включая загрузку процессора, количество свободных портов, и специфичные для каждой АТС атрибуты и свойства;
• события — возникают от смены состояния АТС, включая возникновение ошибок на АТС.

Каждая АТС будет представлена в системе в виде web-сервиса и этот сервис будет по запросу выдавать список поддерживаемых операций. Далее, вызов методов сервиса будет транслироваться в индивидуальные команды конкретной АТС и передаваться на АТС по IP-сети на исполнение. Также, сервис будет посылать JMS сообщения в случае возникновения событий на АТС.

5.9 Обеспечение безопасности системы

Обеспечение безопасности системы осуществляется ограничением взаимодействия (протоколов, портов, сетевых маршрутов) центральных серверов с оборудованием АТС на уровне сетевых маршрутизаторов. На этом же уровне отсекаются атаки перегрузки сети запросами. По настройке маршрутизаторов и включению оборудования в IP-сеть компании будет разработана документация.

Следующий уровень безопасности достигается использованием защищённых протоколов и стандартных алгоритмов шифрования.

Пользователи системы аутентифицируются в системе с помощью пары логин/пароль. Пароль системы хранится в защищённом виде и восстановлению не подлежит — возможно получение нового пароля в случае потери старого. Также безопасность обеспечивается разделением прав (авторизацией) на просмотр и изменение данных в системе. В системе планируется предусмотреть следующие роли пользователей.

• администратор устанавливает роли пользователей;
• оператор работает с клиентскими подключениями и услугами;
• бизнес-аналитик имеет доступ к аналитике по биллинговой информации;
• процесс-аналитик имеет доступ к ключевым показателям эффективности использования системы;
• инженер службы поддержки.

Также при настройке системы ведётся журналирование изменения данных и архивирование данных на ленточных носителях согласно определённым регламентам, что позволяет восстанавливать данные в случае умышленной или неумышленной порчи.

5.10 Повышение отказоустойчивости

Помимо перечисленных программных средств, для обеспечения надежности системы предлагается также использовать внедрённые в АО «Казахтелеком» средства мониторинга и распределения нагрузки по серверам — это позволит вписать создаваемое решение в общую схему управления ИТ-инфраструктурой общества, и, тем самым, сократить эксплуатационные расходы.

6. План-график реализации решения

В данном проекте, для оптимального соотношения цены и качества разработки и кастомизации системы, предполагается задействовать R&D центры нашей компании в Москве, Ульяновске и Смоленске. Штатное расписание: 3 R&D менеджера, архитектор проекта, 2 аналитика, 4 системных администратора, специалист по высоконагруженным системам, релиз-инженер, 8 программистов, 12 инженеров по тестированию ПО, технический писатель. Наши специалисты имеют большой опыт коммерческих разработок оборудования и ПО для ИТ/Телеком компаний в ходе работы как над собственными проектами (CMS Joomla, OpenMeetings, аппаратно-программный терминал ВКС «Пульс-М» и т.д.), так и над проектами крупных ИТ/Телеком производителей оборудования и ПО (Intel, Sun, Alcatel-Lucent, «1С» и т.д.). Кроме того, компания является официальным партнером по разработке программного обеспечения для таких компаний как Intel, Sun, Microsoft, и участвует в Российской ассоциации свободного программного обеспечения (РАСПО) с момента основания этой организации.

Ниже представлен план-график реализации решения, рассчитанный на 16 недель с момента подписания договора.

Примечания:

По этапу 2: заказчик АО «Казахтелеком» должен будет предоставить список ключевых сотрудников и заинтересованных сторон, административную поддержку их анкетирования и интервью.
По этапу 3: заказчик АО «Казахтелеком» должен будет предоставить документацию и консультации, а также административную поддержку интервьюирования заинтересованных сторон по требуемой бизнес-функциональности и интерфейсам с имеющимися системами.
По этапу 4: заказчик АО «Казахтелеком» должен обозначить ключевых сотрудников для консультаций по сетевым элементам, а также предоставить оборудование (сетевые элементы) для пилотного проекта.
По этапу 5: заказчик АО «Казахтелеком» должен предоставить оборудование и обозначить и ключевого сотрудника, для содействия инженерам нашей компании. Место установки, ресурсы питания, сетевые и прочие ресурсы должны быть выделены и полностью готовы не позднее конца 6-й недели.
По этапу 6: заказчик АО «Казахтелеком» должен предоставить оборудование и обозначить ключевого сотрудника, для содействия инженерам нашей компании. Место установки, ресурсы питания, сетевые и прочие ресурсы должны быть выделены и полностью готовы не позднее конца 7-й недели.
По этапу 7: заказчик АО «Казахтелеком» должен обозначить ключевых сотрудников, для содействия и консультаций инженеров нашей компании, по каждой их интегрируемых платформ. Соответствующие каналы связи должны быть выделены и полностью готовы для подключения не позднее конца 8-й недели.
По этапу 8: заказчик АО «Казахтелеком» должен обозначить ключевого сотрудника, для испытаний центрального модуля системы совместно с инженером нашей компании, по предварительно согласованной программе. Соответствующие инженеры по интегрируемым платформам должны быть доступны для оперативного устранения выявляемых в ходе тестирования проблем.
По этапу 9: заказчик АО «Казахтелеком» должен обозначить ключевого сотрудника, для испытаний системы резервного хранения данных совместно с инженером нашей компании, по предварительно согласованной программе.
По этапу 10: заказчик АО «Казахтелеком» должен обозначить ключевого сотрудника, для испытаний WEB интерфейсов совместно с инженером нашей компании, по предварительно согласованной программе.
По этапу 11: заказчик АО «Казахтелеком» должен обозначить ключевого сотрудников, для установки, тестирования, интеграции и испытаний совместно с инженером нашей компании, по предварительно согласованной программе. Заказчик должен гарантировать полную готовность оборудования в пилотной зоне к моменту выезда сотрудника нашей компании в пилотную зону. В случае задержек связанных с отсутствием требуемых для интеграции и тестирования ресурсов, АО «Казахтелеком» оплачивает дополнительные расходы связанные с задержкой пребывания сотрудника в командировке в размере 9 тысяч рублей за каждый день задержки. К этому моменту компанией АО «Казахтелеком» должны быть приняты служебные регламенты для сотрудников о правилах работы с системой.
По этапу 13: Предлагается техническая поддержка в режиме 8/5 (8 часов в день, по будням) сроком на 1 год.
Общее: в случае задержек с реализацией программы по вине заказчика суммарно более чем на 3 дня, АО «Казахтелеком» обязуется компенсировать нашей компании соответствующие расходы.

7. Тестирование/согласование

Для создания распределенной отказоустойчивой системы промышленного качества необходимо уделять внимание тестированию. Также к тестированию относится этап согласования поддерживаемого оборудования, состава программных интерфейсов, функциональности графического интерфейса и т. п. Это позволяет в самом начале разработки отчетливо представлять, какие именно требования предъявляются к системе и значительно сокращают время разработки. Немаловажным фактором представляется и то, что будут выявлены нереалистичные требования к системе.

7.1 Согласование списка станционного оборудования

Для того, чтобы выявить реализуемые возможности АТС и согласовать интерфейс программного адаптера необходимо провести тестирование тех АТС, которые войдут в пилотный проект. На основе этого тестирования предполагается написание псевдо-адаптера, моделирующего функциональность АТС без реального подключения к оборудованию. Это позволит распараллелить процесс разработки.

7.2 Согласование дизайна системы автоматизации управления ресурсами/услугами

Перед началом разработки предполагается провести согласование дизайна с управляющими и техническими службами заказчика. Это позволит отсечь ненужную функциональность и обеспечить безболезненную интеграцию системы в существующую инфраструктуру заказчика. По результатам согласования будет составлена детализированная проектная документация на систему.

7.3 Тестирование базового функционала ядра системы

На этапе завершения создания ядра системы будет проведено тестирование ядра системы в условиях, приближенных к реальным, но с использованием псевдо-адаптеров АТС. Успешное тестирование ядра позволит перейти к следующим шагам построения системы — созданию интерфейсов пользователя, добавление алгоритмов для автоматического управления подключением/отключением услуг и др.

7.4 Испытания модели ядро + адаптеры

Каждый новый адаптер для АТС будет проходить предварительное тестирование на соответствие интерфейсу, документированному по результатам пункта 7.1. Если адаптер соответствует интерфейсу, будет проводиться тестирование связки ядро+адаптер. Данное тестирование позволит выявить проблемы совместимости ядра и адаптера, такие как состязание за ресурсы, согласованность ответов и запросов, задержки по времени и т. п. Если испытание проходит успешно, адаптер считается пригодным и его версия фиксируется в отчетной документации.

7.5 Тестирование взаимодействия новой системы с бизнес-процессами предоставления и обслуживания услуг

На поздних этапах создания проекта предполагается проведение тестирования новой системы с бизнес-процессами заказчика. Система должна соответствовать правилам, установленным на этапе согласования (см. пункт 7.2). Если бизнес-процессы заказчика изменились за время разработки системы, то возможна дополнительная настройка системы под новые требования.

7.6 Тестовые испытания обновленных бизнес-процессов в архитектуре BPEL/SOA

Внедрение системы предполагает обновление бизнес процессов. Для выявления несовместимостей будут проведены испытания в архитектуре BPEL/SOA. При этом необходимо удостовериться не только в работе системы, но и в том, что созданные служебные регламенты приняты сотрудниками компании и работают.

7.7 Проверка документации по эксплуатации и тиражированию вновь вводимой системы

Заблаговременно заказчику будет предоставлена документация по эксплуатации и тиражированию системы на рецензию. Также возможно дополнительное обучение персонала заказчика работе с системой в форме семинаров, в том числе удаленно.

7.8 Испытания проекта в целом в пилотной зоне

В качестве доказательства работоспособности системы будет проведено тестирование всего проекта в целом в пилотной зоне. Данное тестирование позволит помимо этого выявить те улучшения системы, которые не были изложены в исходной проектной документации, но могут быть реализованы нашей командой дополнительно.

8. Приложения

8.1 Коммуникации

Для проведения аудита и внедрения в АО «Казахтелеком» будут командированы сотрудники нашей компании. Для обеспечения связи и сокращения командировочных расходов в процессе аудита и внедрения системы в процессе реализации пилотного проекта в филиалы АО «Казахтелеком» будет установлена система телесовещаний.

8.2 Процесс аудита

Наша компания имеет большой опыт аудита ИТ-инфраструктуры и бизнес-процессов государственных и коммерческих учреждений, а также телекоммуникационных компаний, в том числе операторов большой тройки, департамента природопользования и охраны окружающей среды г. Москвы, ФГУ оценки качества зерна.

8.3 Процесс разработки и контроля качества

Наша компания сертифицирована по международному стандарту ISO 9000, регулярно успешно проходит аккредитации и строит процессы разработки и контроля качества в соответствии с этим стандартом. Помимо этого компания использует современные технологии в области управления изменениями, исходным кодом, релиз инжинирингом и непрерывной интеграции (Maven, Subversion, Hadson). Для улучшения качества регулярно проводятся формальные инспекции архитектурных документов, тестовых планов, готового кода и документации.

8.4 Интерфейс модуль-адаптера

Интерфейс модуля-адаптера строится исходя из следующих этапов транзакции.

• подключения к оборудованию АТС (команды авторизации в качестве суперпользователя станции, прямой доступ к памяти);
• получению команд из ядра системы (получение команд из ядра системы, анализ нагрузки целевых АТС, принятие решения об исполнении команды либо о её кешировании в процессе диалога с пользователем) ;
• преобразованию полученной команды в оригинальный синтаксис целевой системы (преобразование стандартных команд ядра в команды по отображению и модификации абонентской БД станции);
• передача преобразованной команды на оборудование АТС;
• получения результатов выполнения команды;
• проведения анализа полученного результата на заданном уровне (анализ успешности выполнения команды, если команда не была выполнена по причине окончания времени ожидания, сбоя в работе целевого модуля и т.д., повтор команды, либо кеширование, либо отказ от выполнения с индикацией аварийного сообщения);
• возврата результатов в ядро системы.

8.5 Ценовое предложение

Примечание. Потенциальный поставщик может не указывать составляющие общей цены, при этом указанная в данной строке цена рассматривается тендерной комиссией как определенная с учетом всех затрат потенциального поставщика и не подлежит пересмотру.

Техническая спецификация услуг

ИТОГО: 38 690 400,00 тенге.
Данные спецификации будут являться Приложением к Договорам поставки и остаются неизменными в период действия договора.