ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 30.11.2023
Просмотров: 30
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
3.1.3.
Документы,
формируемые
при
тестировании
и
приемке
разрабатываемой системы
Ниже приведен перечень формируемых документов.
3.1.3.1. План тестирования (см. Приложение 1)
Предназначен для фиксирования действий пользователя, совершаемых им при работе с системой, правильность выполнения которых требуется проверить при тестировании.
План тестирования составляется на основе «ИИ», а также функциональных дизайнов.
По результатам тестирования каждого из действий тестирующий пользователь должен указать степень функционирования данного действия: «принято»,
«принято с ошибками», «не принято».
«Принято» означает, что действие или функциональность соответствует описанию в документах и у пользователя нет замечаний.
«Принято с ошибками» означает, что пользователь принимает тестируемую функциональность, но при тестировании выявлены незначительные ошибки, которые не влияют на саму функциональность или действия, связанные с ней.
В этом случае пользователь должен внести замечания в приложение к плану тестирования только с низкой степенью критичности.
Статус «не принято» означает, что во время тестирования были выявлены ошибки или замечания, которые влияют на данную функциональность системы или другую взаимосвязанную функциональность, что не позволяет системе работать корректно в соответствии с ожидаемым результатом. В этом случае пользователь фиксирует замечания и ошибки в приложении к плану тестирования. Такие замечания могут иметь высокую или среднюю степень критичности.
После исправления таких замечаний или ошибок требуется снова отправить данную функциональность на тестирование.
3.1.3.2. Приложение к плану (см. Приложение 2)
Предназначено для фиксирования замечаний или ошибок, выявленных пользователем на этапе тестирования функциональности.
Пользователь заносит краткое описание возникшей ошибки и указывает, к какому пункт плана тестирования относится замечание. Так же пользователь должен указать степень критичности данного замечания или ошибки.
Приложение к плану передается вместе с планом тестирования Менеджеру проекта, который, в свою очередь, передает их сотруднику исполнителя.
Все замечания пользователей должны быть внесены в GPT ответственным сотрудником Исполнителя в соответствии с устоявшейся практикой ведения замечаний.
3.1.3.3. Пользовательская документация
Предназначена для описания действий пользователя, осуществляемых при работе с порталом BIG DATA.
Пользовательская документация выполняется
Исполнителем и согласовывается с экспертом Заказчика.
После этого при внешнем комплексном тестировании она предоставляется вместе с планом тестирования.
Пользователи, тестирующие функциональность, также проверяют описание пользовательской документации. В случае выявления ошибок или замечаний они указывают их и передают Исполнителю на доработку.
После доработки пользовательская документация возвращается на согласование ответственному пользователю и проверяется аналогично описанному выше в этом пункте.
После того как все замечания по документации устранены, она утверждается ответственным пользователем.
3.1.3.4. Акт приемки системы
Составляется по итогам тестирования системы и пользовательской документации, где фиксируется список функциональных блоков портала BIG
DATA и степень готовности данных блоков. Также указывается степень готовности пользовательской документации.
3.2.
План нагрузочного тестирования
План нагрузочного тестирования описывает порядок проведения этапа
«нагрузочное тестирование», необходимого для выявления узких мест разрабатываемой системы и аппаратного обеспечения.
Данный план содержит:
• перечень ресурсов, которые будут привлечены на этапе нагрузочного тестирования;
• цели;
• инструменты для измерения результата достижения целей, и т.д.
План нагрузочного тестирования несет рекомендательный характер и может быть изменен вследствие новых открывшихся обстоятельств при осуществлении работ по нагрузочному тестированию.
Основной средой проведения нагрузочного тестирования является тестовое приложение разработанной системы (BIG DATA).
Во время проведения нагрузочного тестирования не допускается наличие явных ошибок, по которым не закрыты задачи по исправлению в GPT.
Если такие задачи существуют, по каждой их них принимается отдельное решение о влиянии на функционал приложения и возможном влиянии на результаты проведения интеграционного тестирования.
3.2.1.
Компонентное нагрузочное тестирование
Этап компонентного тестирования заключается в нагрузочном тестировании нескольких основных крупных модификаций с целью выявления узких мест в модификациях и оптимизации разработанного кода.
К основным модификациям можно отнести следующие:
• DIN01 web-форма «Журнал дилера»;
• DIN03 web-форма «Виртуальные контракты»;
• DIN05 web-форма «Операции».
Нагрузочное тестирование каждой модификации будет происходить после завершения этапа внутреннего функционального тестирования и перед ее передачей эксперту Заказчика на функциональное тестирование.
3.2.2.
Комплексное нагрузочное тестирование
Комплексное нагрузочное тестирование заключается в тестировании разработанного портала в полнофункциональном режиме, когда все модификации будут полностью протестированы и скомпилированы в одно приложение.
Этап комплексного нагрузочного тестирования проходит после общей компиляции разработанного приложения перед этапом тестирования Заказчиком проекта.
Повторное проведение этапа нагрузочного тестирования будет проведено после тестирования Заказчиком проекта и перед подписанием документа «Акт приемки».
Все этапы нагрузочного тестирования выполняются ответственным сотрудником
Исполнителя в соответствии с правилами процедуры тестирования.
Время на проведение каждого этапа тестирования будет обговариваться сторонами перед началом каждого отдельного теста и указываться в «Протоколе тестирования» по окончании теста.
3.2.3.
Процедура тестирования
3.2.3.1. Компонентное тестирование
Перед началом этапа тестирования сотрудник Исполнителя составляет сценарий тестирования для каждой из основных модификаций и согласует его с экспертом
Заказчика.
Тестирование будет проводиться в разработанной программной среде.
Программной средой может быть приложение с разработанной модификацией, которая будет тестироваться, а также данные, на которых будет проводиться тестирование.
Во время тестирования ответственный сотрудник Исполнителя собирает полученные данные с помощью соответствующих инструментов, после чего готовит «Протокол тестирования» по итогам тестирования.
3.2.3.2. Комплексное тестирование
Для проведения данного этапа также требуется составление сценария для тестирования полного функционала разработанной системы модификаций.
Сценарий тестирования согласуется с экспертом Заказчика.
Средой тестирования должно выступать полностью разработанное приложение, в котором на момент проведения тестирования не выявлено критических ошибок, влияющих на функционал. Также средой тестирования могут быть реальные данные, импортированные в тестовую систему.
Оборудование для проведения комплексного тестирования должно соответствовать описанному в документе «Технический дизайн на среду для опытного тестирования».
Во время тестирования ответственный сотрудник со стороны Исполнителя собирает полученные результаты и готовит «Протокол тестирования» по итогам тестирования. На основе протокола обеими сторонами принимается решение о готовности разработанного приложения.
3.2.4.
Обработка результатов тестирования
При рассмотрении протокола тестирования на каждом из этапов обеими сторонам совместно принимается решение о готовности отдельных компонентов или функционала в целом.
Могут быть получены следующие результаты:
1.
Результат проведенного тестирования удовлетворяет обе стороны, и работа продолжается.
2.
Результат проведенного тестирования не полностью удовлетворяет обе стороны. На этом основании сотрудник Исполнителя фиксирует список требований, которые должны быть выполнены для перехода к следующему этапу проекта или тестирования. Принимается совместное решение о возможности продолжения работ до исправления выявленных ошибок и замечаний. Замечания должны быть внесены в GPT соответствующим образом.
3.2.5.
Используемые инструменты и другое обеспечение
Для проведения нагрузочного тестирования будет использована программа
Microsoft Application Center Test из пакета Visual Studio 2003. С помощью этого инструмента будут подготавливаться сценарии тестирования, запускаться созданные сценарии и собираться данные по их работе.
Эта программа ранее была использована при нагрузочном тестировании пилотного проекта BIG DATA.
Для отслеживания нагрузки на аппаратное обеспечение будет использоваться программа Microsoft System Performance Monitor, входящая в стандартный пакет
ОС Windows. Для выявления каких-либо проблем, связанных со временем
Если консультант ранее не участвовал в проекте ИИ, следует осуществить его обучение. С этой целью необходимо ввести его в проект и обучить (передать знания) к началу этапа «начальная поддержка».
Назначенный консультант будет осуществлять прямое взаимодействие с пользователями портала BIG DATA. Как упоминалось выше, ведение замечаний и сообщений об ошибках должно осуществляться в соответствии с устоявшейся процедурой сбора и обработки замечаний в MR.
Все остальные вопросы поддержки будут решаться в рамках существующего проекта BIG DATA по поддержке основного решения.
5.
План развертывания приложений
5.1.
Приложения, подлежащие миграции/развертыванию
Внедрение нового портала BIG DATA затрагивает ряд приложений или сервисов, которые нужно развернуть или перенастроить. К данным процессам относятся:
1)
миграция web-интерфейса. На web-сервере необходимо провести настройку таким образом, чтобы по прежнему URL был доступ к новому порталу BIG DATA;
2)
миграция OLAP-системы. Для OLAP-системы необходимо переключить источник данных со старого BIG DATA на новый портал. Процедура описывается в разделе «Контроль миграции данных OLAP»;
3)
миграция плазменных панелей. Для плазменных панелей (ПП) по аналогии с OLAP необходимо переключить источник данных;
4)
развертывание нового портала BIG DATA. Необходимо выполнить развертывание нового портала BIG DATA в промышленной среде.
5.2.
Миграция web-интерфейса
Как упоминалось выше, провести настройку на web-сервере необходимо так, чтобы по прежнему URL сохранился доступ к новому порталу BIG DATA.
Выполняется это силами IT-специалиста. Операция стандартная, тестирования не требует. Переключение будет произведено в момент внедрения решения в промышленную среду.
До внедрения в промышленную среду доступ к новому порталу будет осуществляться по внутреннему временному URL.
5.3.
Миграция OLAP
Процесс миграции источника данных OLAP заключается в простой замене текущих SQL-запросов к данным на новые разработанные запросы.
5.4.
Миграция ПП
Процесс миграции источника данных для ПП заключается в простой замене пакета DTS на другой пакет.
5.5.
Развертывание нового портала BIG DATA
Разработка функционала BIG DATA будет вестись на приложении для разработки
MR_DEV_INT
. Тестирование – на приложении MR_TST_EXT.
5.5.1.
Перенос приложения из среды разработки в среду тестирования
Процесс состоит из двух этапов:
1) экспорт модификаций из среды разработки;
2) импорт модификаций в среду тестирования.
5.5.1.1. Экспорт
Все завершённые разработчиком модификации переносятся из среды разработки в среду тестирования экспортом проектов с программным кодом и метками согласно действующей процедуре обновления информационного ресурса Microsoft Dynamics™ AX (MR Develop Systems Update Procedure). То есть проекты экспортируются из среды разработки, готовится инструкция по обновлению (при необходимости инструкция содержит описание изменения структуры данных (если были изменения), информацию о наличии/отсутствии меток, о необходимости или отсутствии необходимости запускать джобы, модифицирующие данные, после импорта проекта), проекты выкладываются в определённую сетевую директорию.
5.5.1.2. Импорт
Ответственный сотрудник отдела ИС информируется разработчиком модификации либо консультантом, ее проводящим тестирование, о необходимости переноса модификации на тестовое приложение. Контроль исполнения осуществляет консультант IT1.
5.5.2.
Перенос приложения из среды тестирования в рабочую среду
Перенос модификаций в рабочую среду осуществляется согласно действующей процедуре обновления информационного ресурса Microsoft
Dynamics
™ AX (Update Procedure) ответственным сотрудником отдела ИС.
5.5.3.
Подготовительные
действия
для
подготовки
сред
перед
развёртыванием
На этапе разработки и тестирования отдельных модификаций установка дополнительных IIS (Internet Information Services) и АОС не потребуется.
Разработка и тестирование будут проводиться на имеющемся программном и аппаратном обеспечении. Дополнительное оборудование и программное обеспечение понадобятся к этапу нагрузочного тестирования, которое будет проводиться в среде, описанной в документе «Технический дизайн на среду для опытного тестирования». Лицензия на дополнительный АОС не понадобится, т. к. у Клиента есть лицензия на два АОС и в данный момент используется только один (IIS входит в Windows). Развёртывание ПО в среде для опытного тестирования производится силами отдела ИС Клиента с привлечением ответственных сотрудников IT1 (вероятно, ведущего разработчика).
Документы,
формируемые
при
тестировании
и
приемке
разрабатываемой системы
Ниже приведен перечень формируемых документов.
3.1.3.1. План тестирования (см. Приложение 1)
Предназначен для фиксирования действий пользователя, совершаемых им при работе с системой, правильность выполнения которых требуется проверить при тестировании.
План тестирования составляется на основе «ИИ», а также функциональных дизайнов.
По результатам тестирования каждого из действий тестирующий пользователь должен указать степень функционирования данного действия: «принято»,
«принято с ошибками», «не принято».
«Принято» означает, что действие или функциональность соответствует описанию в документах и у пользователя нет замечаний.
«Принято с ошибками» означает, что пользователь принимает тестируемую функциональность, но при тестировании выявлены незначительные ошибки, которые не влияют на саму функциональность или действия, связанные с ней.
В этом случае пользователь должен внести замечания в приложение к плану тестирования только с низкой степенью критичности.
Статус «не принято» означает, что во время тестирования были выявлены ошибки или замечания, которые влияют на данную функциональность системы или другую взаимосвязанную функциональность, что не позволяет системе работать корректно в соответствии с ожидаемым результатом. В этом случае пользователь фиксирует замечания и ошибки в приложении к плану тестирования. Такие замечания могут иметь высокую или среднюю степень критичности.
После исправления таких замечаний или ошибок требуется снова отправить данную функциональность на тестирование.
3.1.3.2. Приложение к плану (см. Приложение 2)
Предназначено для фиксирования замечаний или ошибок, выявленных пользователем на этапе тестирования функциональности.
Пользователь заносит краткое описание возникшей ошибки и указывает, к какому пункт плана тестирования относится замечание. Так же пользователь должен указать степень критичности данного замечания или ошибки.
Приложение к плану передается вместе с планом тестирования Менеджеру проекта, который, в свою очередь, передает их сотруднику исполнителя.
Все замечания пользователей должны быть внесены в GPT ответственным сотрудником Исполнителя в соответствии с устоявшейся практикой ведения замечаний.
3.1.3.3. Пользовательская документация
Предназначена для описания действий пользователя, осуществляемых при работе с порталом BIG DATA.
Пользовательская документация выполняется
Исполнителем и согласовывается с экспертом Заказчика.
После этого при внешнем комплексном тестировании она предоставляется вместе с планом тестирования.
Пользователи, тестирующие функциональность, также проверяют описание пользовательской документации. В случае выявления ошибок или замечаний они указывают их и передают Исполнителю на доработку.
После доработки пользовательская документация возвращается на согласование ответственному пользователю и проверяется аналогично описанному выше в этом пункте.
После того как все замечания по документации устранены, она утверждается ответственным пользователем.
3.1.3.4. Акт приемки системы
Составляется по итогам тестирования системы и пользовательской документации, где фиксируется список функциональных блоков портала BIG
DATA и степень готовности данных блоков. Также указывается степень готовности пользовательской документации.
3.2.
План нагрузочного тестирования
План нагрузочного тестирования описывает порядок проведения этапа
«нагрузочное тестирование», необходимого для выявления узких мест разрабатываемой системы и аппаратного обеспечения.
Данный план содержит:
• перечень ресурсов, которые будут привлечены на этапе нагрузочного тестирования;
• цели;
• инструменты для измерения результата достижения целей, и т.д.
План нагрузочного тестирования несет рекомендательный характер и может быть изменен вследствие новых открывшихся обстоятельств при осуществлении работ по нагрузочному тестированию.
Основной средой проведения нагрузочного тестирования является тестовое приложение разработанной системы (BIG DATA).
Во время проведения нагрузочного тестирования не допускается наличие явных ошибок, по которым не закрыты задачи по исправлению в GPT.
Если такие задачи существуют, по каждой их них принимается отдельное решение о влиянии на функционал приложения и возможном влиянии на результаты проведения интеграционного тестирования.
3.2.1.
Компонентное нагрузочное тестирование
Этап компонентного тестирования заключается в нагрузочном тестировании нескольких основных крупных модификаций с целью выявления узких мест в модификациях и оптимизации разработанного кода.
К основным модификациям можно отнести следующие:
• DIN01 web-форма «Журнал дилера»;
• DIN03 web-форма «Виртуальные контракты»;
• DIN05 web-форма «Операции».
Нагрузочное тестирование каждой модификации будет происходить после завершения этапа внутреннего функционального тестирования и перед ее передачей эксперту Заказчика на функциональное тестирование.
3.2.2.
Комплексное нагрузочное тестирование
Комплексное нагрузочное тестирование заключается в тестировании разработанного портала в полнофункциональном режиме, когда все модификации будут полностью протестированы и скомпилированы в одно приложение.
Этап комплексного нагрузочного тестирования проходит после общей компиляции разработанного приложения перед этапом тестирования Заказчиком проекта.
Повторное проведение этапа нагрузочного тестирования будет проведено после тестирования Заказчиком проекта и перед подписанием документа «Акт приемки».
Все этапы нагрузочного тестирования выполняются ответственным сотрудником
Исполнителя в соответствии с правилами процедуры тестирования.
Время на проведение каждого этапа тестирования будет обговариваться сторонами перед началом каждого отдельного теста и указываться в «Протоколе тестирования» по окончании теста.
3.2.3.
Процедура тестирования
3.2.3.1. Компонентное тестирование
Перед началом этапа тестирования сотрудник Исполнителя составляет сценарий тестирования для каждой из основных модификаций и согласует его с экспертом
Заказчика.
Тестирование будет проводиться в разработанной программной среде.
Программной средой может быть приложение с разработанной модификацией, которая будет тестироваться, а также данные, на которых будет проводиться тестирование.
Во время тестирования ответственный сотрудник Исполнителя собирает полученные данные с помощью соответствующих инструментов, после чего готовит «Протокол тестирования» по итогам тестирования.
3.2.3.2. Комплексное тестирование
Для проведения данного этапа также требуется составление сценария для тестирования полного функционала разработанной системы модификаций.
Сценарий тестирования согласуется с экспертом Заказчика.
Средой тестирования должно выступать полностью разработанное приложение, в котором на момент проведения тестирования не выявлено критических ошибок, влияющих на функционал. Также средой тестирования могут быть реальные данные, импортированные в тестовую систему.
Оборудование для проведения комплексного тестирования должно соответствовать описанному в документе «Технический дизайн на среду для опытного тестирования».
Во время тестирования ответственный сотрудник со стороны Исполнителя собирает полученные результаты и готовит «Протокол тестирования» по итогам тестирования. На основе протокола обеими сторонами принимается решение о готовности разработанного приложения.
3.2.4.
Обработка результатов тестирования
При рассмотрении протокола тестирования на каждом из этапов обеими сторонам совместно принимается решение о готовности отдельных компонентов или функционала в целом.
Могут быть получены следующие результаты:
1.
Результат проведенного тестирования удовлетворяет обе стороны, и работа продолжается.
2.
Результат проведенного тестирования не полностью удовлетворяет обе стороны. На этом основании сотрудник Исполнителя фиксирует список требований, которые должны быть выполнены для перехода к следующему этапу проекта или тестирования. Принимается совместное решение о возможности продолжения работ до исправления выявленных ошибок и замечаний. Замечания должны быть внесены в GPT соответствующим образом.
3.2.5.
Используемые инструменты и другое обеспечение
Для проведения нагрузочного тестирования будет использована программа
Microsoft Application Center Test из пакета Visual Studio 2003. С помощью этого инструмента будут подготавливаться сценарии тестирования, запускаться созданные сценарии и собираться данные по их работе.
Эта программа ранее была использована при нагрузочном тестировании пилотного проекта BIG DATA.
Для отслеживания нагрузки на аппаратное обеспечение будет использоваться программа Microsoft System Performance Monitor, входящая в стандартный пакет
ОС Windows. Для выявления каких-либо проблем, связанных со временем
загрузки или производительностью базы данных Oracle, будет использоваться
Automatic Workload Repository (
опция Oracle 10g Release 2).
Требования к использованию аппаратного обеспечения описаны в документе
«Технический дизайн на среду для опытного тестирования».
3.2.6.
Цели и показатели
Основным критерием оценки быстродействия портала будем считать время, требуемое на загрузку web-страницы на стороне клиента, которое не должно превышать 5 секунд при скорости канала 100 Мбит/с.
При этом необходимо, чтобы нагрузка на аппаратное обеспечение не превышала следующих показателей:
• средняя нагрузка процессорной мощности сервера БД – не более 60 %;
• среднее потребление памяти Business Connector – не более 50 MБ на 1 пользователя.
Для каждого из этапов (компонентного, комплексного) необходимо провести несколько итераций с разными параметрами.
Необходимо рассмотреть подключение в условиях ограниченного канала (56 кбит/с, размер загружаемой страницы не более 55 кБ, время на загрузку не более
10 с), инструментальное тестирование (например, 15 пользователей; сеть 100
Мбит/c), экстремальное тестирование для определения предела производительности (не менее 250 пользователей) надо провести для комплексного тестирования.
4.
План поддержки
Данный раздел описывает различные этапы технического сопровождения, которое будет предоставлено Заказчику после запуска системы.
Ниже приведено описание того, как будет происходить сопровождение и распределение обязанностей по сопровождению.
4.1.
Начальная поддержка
Осуществляется в первый месяц после запуска системы в эксплуатацию.
Поддержка на данном этапе является частью проекта ИИ, и все работы по поддержке ведутся в рамках проекта.
В случае возникновения инцидента пользователь системы сообщает эксперту со стороны Заказчика. Они совместно выявляют причину возникновения проблемы и устанавливают, является ли это ошибкой системы.
Если этот инцидент действительно является ошибкой системы, то эксперт сообщает об этом ответственному сотруднику со стороны Исполнителя, который,
Automatic Workload Repository (
опция Oracle 10g Release 2).
Требования к использованию аппаратного обеспечения описаны в документе
«Технический дизайн на среду для опытного тестирования».
3.2.6.
Цели и показатели
Основным критерием оценки быстродействия портала будем считать время, требуемое на загрузку web-страницы на стороне клиента, которое не должно превышать 5 секунд при скорости канала 100 Мбит/с.
При этом необходимо, чтобы нагрузка на аппаратное обеспечение не превышала следующих показателей:
• средняя нагрузка процессорной мощности сервера БД – не более 60 %;
• среднее потребление памяти Business Connector – не более 50 MБ на 1 пользователя.
Для каждого из этапов (компонентного, комплексного) необходимо провести несколько итераций с разными параметрами.
Необходимо рассмотреть подключение в условиях ограниченного канала (56 кбит/с, размер загружаемой страницы не более 55 кБ, время на загрузку не более
10 с), инструментальное тестирование (например, 15 пользователей; сеть 100
Мбит/c), экстремальное тестирование для определения предела производительности (не менее 250 пользователей) надо провести для комплексного тестирования.
4.
План поддержки
Данный раздел описывает различные этапы технического сопровождения, которое будет предоставлено Заказчику после запуска системы.
Ниже приведено описание того, как будет происходить сопровождение и распределение обязанностей по сопровождению.
4.1.
Начальная поддержка
Осуществляется в первый месяц после запуска системы в эксплуатацию.
Поддержка на данном этапе является частью проекта ИИ, и все работы по поддержке ведутся в рамках проекта.
В случае возникновения инцидента пользователь системы сообщает эксперту со стороны Заказчика. Они совместно выявляют причину возникновения проблемы и устанавливают, является ли это ошибкой системы.
Если этот инцидент действительно является ошибкой системы, то эксперт сообщает об этом ответственному сотруднику со стороны Исполнителя, который,
в свою очередь, фиксирует в GPT запрос об инциденте, где описывает возникшую ошибку.
Также при необходимости ответственный сотрудник Заказчика может и сам сформировать запрос в GPT.
Степень критичности инцидента устанавливается совместно представителем
Заказчика и Исполнителя. Она может быть высокой, средней и низкой. В соответствии со степенью критичности осуществляется исправление данного инцидента.
Дальнейшая работа по устранению проблем ведется в соответствии с устоявшейся процедурой обработки замечаний, принятой в MR.
По итогам этапа начальной поддержки формируется документ «Акт приемки», который определяет готовность к переводу системы полностью в промышленную эксплуатацию.
После подписания акта обеими сторонами считается, что проект ИИ переводится на этап «Основной поддержки» и будет относиться к проекту Big Data.
4.2.
Основная поддержка
Начинается с момента подписания акта приемки.
Ведение всех запросов относится к проекту BIG DATA, в рамках которого также ведется поддержка основной функциональности, разработанной для MR.
Первоначально обращения всех пользователей системы проходят через ответственных сотрудников MR.
В том случае, когда ответственный сотрудник MR не может сам установить причину возникновения проблемы, он обращается за помощью к ответственному сотруднику Исполнителя, который, в свою очередь, действуя согласно документу
«Процедура обработки замечаний», фиксирует данное замечание/инцидент в
GPT.
Сотрудник MR и сотрудник Исполнителя совместно принимают решение о критичности данного замечания или сотрудник Исполнителя может сделать это самостоятельно при фиксировании замечания/инцидента.
Только после этого сотрудник Исполнителя приступает к исправлению данного замечания/инцидента.
Ведение замечания/инцидента должно соответствовать устоявшейся процедуре обработки замечаний, существующей в MR.
4.2.1.1. Обеспечение Исполнителем этапа основной поддержки
Исполнитель предоставляет консультанта на срок не менее 6 месяцев с момента старта этапа основной поддержки. На время работы этого консультанта составляется отдельный договор по оказанию соответствующих услуг.
Также при необходимости ответственный сотрудник Заказчика может и сам сформировать запрос в GPT.
Степень критичности инцидента устанавливается совместно представителем
Заказчика и Исполнителя. Она может быть высокой, средней и низкой. В соответствии со степенью критичности осуществляется исправление данного инцидента.
Дальнейшая работа по устранению проблем ведется в соответствии с устоявшейся процедурой обработки замечаний, принятой в MR.
По итогам этапа начальной поддержки формируется документ «Акт приемки», который определяет готовность к переводу системы полностью в промышленную эксплуатацию.
После подписания акта обеими сторонами считается, что проект ИИ переводится на этап «Основной поддержки» и будет относиться к проекту Big Data.
4.2.
Основная поддержка
Начинается с момента подписания акта приемки.
Ведение всех запросов относится к проекту BIG DATA, в рамках которого также ведется поддержка основной функциональности, разработанной для MR.
Первоначально обращения всех пользователей системы проходят через ответственных сотрудников MR.
В том случае, когда ответственный сотрудник MR не может сам установить причину возникновения проблемы, он обращается за помощью к ответственному сотруднику Исполнителя, который, в свою очередь, действуя согласно документу
«Процедура обработки замечаний», фиксирует данное замечание/инцидент в
GPT.
Сотрудник MR и сотрудник Исполнителя совместно принимают решение о критичности данного замечания или сотрудник Исполнителя может сделать это самостоятельно при фиксировании замечания/инцидента.
Только после этого сотрудник Исполнителя приступает к исправлению данного замечания/инцидента.
Ведение замечания/инцидента должно соответствовать устоявшейся процедуре обработки замечаний, существующей в MR.
4.2.1.1. Обеспечение Исполнителем этапа основной поддержки
Исполнитель предоставляет консультанта на срок не менее 6 месяцев с момента старта этапа основной поддержки. На время работы этого консультанта составляется отдельный договор по оказанию соответствующих услуг.
Если консультант ранее не участвовал в проекте ИИ, следует осуществить его обучение. С этой целью необходимо ввести его в проект и обучить (передать знания) к началу этапа «начальная поддержка».
Назначенный консультант будет осуществлять прямое взаимодействие с пользователями портала BIG DATA. Как упоминалось выше, ведение замечаний и сообщений об ошибках должно осуществляться в соответствии с устоявшейся процедурой сбора и обработки замечаний в MR.
Все остальные вопросы поддержки будут решаться в рамках существующего проекта BIG DATA по поддержке основного решения.
5.
План развертывания приложений
5.1.
Приложения, подлежащие миграции/развертыванию
Внедрение нового портала BIG DATA затрагивает ряд приложений или сервисов, которые нужно развернуть или перенастроить. К данным процессам относятся:
1)
миграция web-интерфейса. На web-сервере необходимо провести настройку таким образом, чтобы по прежнему URL был доступ к новому порталу BIG DATA;
2)
миграция OLAP-системы. Для OLAP-системы необходимо переключить источник данных со старого BIG DATA на новый портал. Процедура описывается в разделе «Контроль миграции данных OLAP»;
3)
миграция плазменных панелей. Для плазменных панелей (ПП) по аналогии с OLAP необходимо переключить источник данных;
4)
развертывание нового портала BIG DATA. Необходимо выполнить развертывание нового портала BIG DATA в промышленной среде.
5.2.
Миграция web-интерфейса
Как упоминалось выше, провести настройку на web-сервере необходимо так, чтобы по прежнему URL сохранился доступ к новому порталу BIG DATA.
Выполняется это силами IT-специалиста. Операция стандартная, тестирования не требует. Переключение будет произведено в момент внедрения решения в промышленную среду.
До внедрения в промышленную среду доступ к новому порталу будет осуществляться по внутреннему временному URL.
5.3.
Миграция OLAP
Процесс миграции источника данных OLAP заключается в простой замене текущих SQL-запросов к данным на новые разработанные запросы.
5.4.
Миграция ПП
Процесс миграции источника данных для ПП заключается в простой замене пакета DTS на другой пакет.
5.5.
Развертывание нового портала BIG DATA
Разработка функционала BIG DATA будет вестись на приложении для разработки
MR_DEV_INT
. Тестирование – на приложении MR_TST_EXT.
5.5.1.
Перенос приложения из среды разработки в среду тестирования
Процесс состоит из двух этапов:
1) экспорт модификаций из среды разработки;
2) импорт модификаций в среду тестирования.
5.5.1.1. Экспорт
Все завершённые разработчиком модификации переносятся из среды разработки в среду тестирования экспортом проектов с программным кодом и метками согласно действующей процедуре обновления информационного ресурса Microsoft Dynamics™ AX (MR Develop Systems Update Procedure). То есть проекты экспортируются из среды разработки, готовится инструкция по обновлению (при необходимости инструкция содержит описание изменения структуры данных (если были изменения), информацию о наличии/отсутствии меток, о необходимости или отсутствии необходимости запускать джобы, модифицирующие данные, после импорта проекта), проекты выкладываются в определённую сетевую директорию.
5.5.1.2. Импорт
Ответственный сотрудник отдела ИС информируется разработчиком модификации либо консультантом, ее проводящим тестирование, о необходимости переноса модификации на тестовое приложение. Контроль исполнения осуществляет консультант IT1.
5.5.2.
Перенос приложения из среды тестирования в рабочую среду
Перенос модификаций в рабочую среду осуществляется согласно действующей процедуре обновления информационного ресурса Microsoft
Dynamics
™ AX (Update Procedure) ответственным сотрудником отдела ИС.
5.5.3.
Подготовительные
действия
для
подготовки
сред
перед
развёртыванием
На этапе разработки и тестирования отдельных модификаций установка дополнительных IIS (Internet Information Services) и АОС не потребуется.
Разработка и тестирование будут проводиться на имеющемся программном и аппаратном обеспечении. Дополнительное оборудование и программное обеспечение понадобятся к этапу нагрузочного тестирования, которое будет проводиться в среде, описанной в документе «Технический дизайн на среду для опытного тестирования». Лицензия на дополнительный АОС не понадобится, т. к. у Клиента есть лицензия на два АОС и в данный момент используется только один (IIS входит в Windows). Развёртывание ПО в среде для опытного тестирования производится силами отдела ИС Клиента с привлечением ответственных сотрудников IT1 (вероятно, ведущего разработчика).
1 2 3