СОДЕРЖАНИЕ
Элементы оглавления не найдены.
Примените стили заголовков, чтобы составить оглавление.
АННОТАЦИЯ
«Тестер изделия "Барьер"» представляет из себя программное средство автоматизации тестирования и наладки. Средство позволяет в полуавтоматическом режиме путём сравнения заданных входных токов и измеренных выходные токов осуществлять наладку изделий.
В результате развития «Тестер изделия "Барьер"» будет содержать следующие модули:
1. Модуль ручного управления.
2. Модуль автоматического управления.
3. Модуль взаимосвязи с изделием.
1 Архитектура и Инфраструктура
«Тестер изделия "Барьер"» представляет из себя программное средство автоматизации тестирования и наладки. Средство позволяет в полуавтоматическом режиме путём сравнения заданных входных токов и измеренных выходные токов осуществлять наладку изделий.
«Тестер изделия "Барьер"» реализован как автономное программное обеспечение для конечного пользователя. Программа «Тестер изделия "Барьер"» не использует сторонних библиотек и сервисов, программе не нужен выход в интернет, программа может работать под операционными системами Windows и Linux.
1.1 Масштабируемость
Программа работает под управлением ОС Windows и Linux.
Программа не использует интернет.
1.2 Основные модули
Программное обеспечение состоит из следующих компонентов:
1. Модуль ручного управления.
2. Модуль автоматического управления.
3. Модуль взаимосвязи с изделием.
2 Процессы жизненного цикла программного обеспечения
Контактная информация офиса разработки:
117393, Москва г, ул. Профсоюзная, д. 56, этаж 17, пом. 32
Контактный телефон - +7 (495) 003 13 25
Сайт - https://kstek.ru/
Электронная почта - info@kstek.ru
Электронная почта для отзывов о продукте: info@kstek.ru
Время работы Пн.-Пт. 10:00 – 18-00
2.1 Жизненный цикл ПО
Жизненный цикл разработки ПО основан на ГОСТ 34.601-90.
1 Формирование требований к программному обеспечению
1.1 Обследование объекта и обоснование необходимости создания ПО
1.2 Построение бизнес-процессов, которые будут автоматизированы при внедрении ПО
1.3 Формирование бизнес требований к разрабатываемому ПО
1.4 Формирование требований к элементам системы
1.5 Формирование требований к дизайн системе ПО
1.6 Формирование требований к среде разработки ПО
1.7 Предварительный анализ сроков по реализации ПО
2 Разработка технического задания
2.1 Разработка и утверждение технического задания на создание ПО
2.2 Определение рабочей группы, ответственной на разработку
2.3 Построение план-графика по отчетным встречам разработки ПО
3 Эскизный проект
3.1 Разработка предварительных проектных решений по системе и её частям
3.2 Разработка документации и комментирование кода
4 Рабочая документация
4.1 Разработка рабочей документации на программу и её части
4.2 Разработка API
5 Разработка и адаптация программ
5.1 Разработка модулей
5.2 Подготовка релизной версии
5.3 Аудит ПО на предмет соответствия требованиям
6 Тестирование ПО
6.1 Тестирование безопасности
6.2 Функциональное тестирование
6.3 Тестирование производительности
6.4 Юзабилити тестирование
6.5 Подготовка отчета о тестировании
7 Ввод в эксплуатацию
7.1 Обучение персонала
7.2 Сбор обратной связи от персонала
8. Сопровождение ПО
8.1 Выполнение работ в соответствии с гарантийными обязательствами
8.2 Послегарантийное обслуживание
2.2 Данные о процессе разработки ПО
Данные о персонале, задействованном в процессе разработки, приведены в главе 4.
Аппаратная среда разработки описана в главе 2.4.
Возможные технические неисправности среды разработки исправляются в рабочее время одним из разработчиков или системным администратором офисов, по договоренности с руководителем.
2.3 Процессы поддержки ПО, в которые вовлечены разработчики
1. Процесс управления документацией
1.1. Определение критериев для сопровождения документации
1.2. Актуализация и доработка документации при изменении ПО
2. Управление конфигурацией ПО
2.1. Контроль модификаций и версий ПО
2.2. Подготовка технической документации по релизу версии ПО
2.3. Исправление ошибок и нестыковок с новыми версиями стороннего ПО
2.4. Плановая модернизация
2.4 Рекомендуемые ТТХ ПК
Разработка ведется в изолированном сегменте офисной сети с 1 АРМ разработчика и одним выделенным сервером.
Аппаратная часть:
Языки программирования, применявшиеся при разработке ПО:
С++, Qt5, MinGW 32-bit (64-bit).
Среда разработки ПО:
Qt Creator, 1 АРМ программиста.
Для корректной работы с программой необходима следующая конфигурация автоматизированного рабочего места пользователя:
Минимальные требования к системе – 1 ядро.
4 Gb RAM доступной памяти.
10Gb свободного места на SSD или HDD.
Поддерживаемые ОС:
Linux, вне зависимости от конкретного дистрибутива.
Windows 7 или выше
3 Порядок технической поддержки ПО
Контактная информация технической поддержки:
Адрес: 117393, Москва г, ул. Профсоюзная, д. 56, этаж 17, пом. 32
Контактный телефон - +7 (495) 003 13 25
Сайт - https://kstek.ru/
Электронная почта - info@kstek.ru
Электронная почта для отзывов о продукте: info@kstek.ru
Время работы Пн.-Пт. 10:00 – 18-00
3.1 Формирование заявки
При поступлении обращения в каналы связи технической поддержки, на такое обращение заводится заявка в SD - таким образом обращение фиксируется, ему присваивается порядковый номер и соответствующие признаки – атрибуты, для дальнейшей работы по обращению и анализу причин обращения.
Регистрацию обращений в SD выполняют преимущественно специалисты 1-й линии технической поддержки, кроме случаев выявления проблем инженерами других линий (2,3 линия).
3.2 Обработка заявки специалистом servicedesk (1-я линия)
В процессе оформления заявки по обращению, специалисты заводят данные об авторе заявки, сути обращения автора заявки в техническую поддержку, наименование ресурсов, которые задействованы у заявителя. Определяет категорию обращения, и исходя из этого принимает решение о выполнении заявки своими силами или эскалации её на уровень инженеров 2-й линии технической поддержки.
Специалист 1-й линии выполняет работы по обращениям и инцидентам всеми доступными ему силами и средствами (собственные навыки, консультации с другими сотрудниками IT инфраструктуры, знания, получаемые из иных компетентных источников).
О ходе работ и способах решения проблемы, делает соответствующие примечания в комментарии. После выполнения работ по обращению и уточнения у заявителя, решена ли задача по обращению, заявка в SD переводится в статус «решена» (после этого заявителю приходит запрос на «утверждение» закрытия заявки по обращению). Если заявитель подтверждает, заявка считается не «решённой», а «закрытой». Инцидент или обращение, так же после этого считается закрытым.
3.3 Эскалация заявки
Эскалация заявки с 1-й линии технической поддержки на вторую происходит в следующих случаях:
Для выполнения заявки требуются доступы к обслуживаемому ресурсу, которых нет у специалистов 1-й линии технической поддержки.
Для выполнения заявки требуется более высокий уровень компетенции, чем есть у специалистов 1-й линии ТП, для решения заявки согласно SLA.
3.4 Обработка заявки 2-й линией
Инженеры 2-й линии технической поддержки:
Решают инциденты, переданных с первого уровня. Если для первого уровня поддержки ожидается, что он решает 80% инцидентов, то от второго уровня поддержки ожидается, что он решает 75% инцидентов, переданных ему первым уровнем, то есть 15% от числа зарегистрированных инцидентов. Остальные инциденты передаются на третий уровень.
Определяют причины проблем.Второй уровень поддержки определяет причины проблем и предлагает меры по их обходу или устранению. Они привлекают и управляют другими ресурсами по мере необходимости для определения причин. Решение проблем передается на третий уровень, когда причина заключается в архитектурном или техническом вопросе, который превышает их уровень квалификации.
Обеспечивают реализацию исправлений и устранений проблем. Второй уровень поддержки обеспечивает инициирование запросов на изменения в проектах, ведущихся в организациях разработчиков, для реализации планов устранения известных ошибок. Они обеспечивают документирование найденных решений, сообщают о них персоналу первого уровня и реализуют их в инструментах
Второй уровень поддержки пытается идентифицировать проблемы до возникновения инцидентов посредством наблюдения за компонентами инфраструктуры и принятия корректирующих действий при обнаружении дефектов или ошибочных тенденций.
Заблаговременно анализируют тенденции инцидентов. Уже случившиеся инциденты исследуются для того, чтобы определить не свидетельствуют ли они о наличии проблем, которые следует исправить, чтобы они не вызвали новые инциденты. Исследуются те инциденты, которые закрыты и не сопоставлены известным проблемам, на предмет наличия потенциальных проблем.
3.5 Механизм эскалации инцидента со второй линии на 3-ю
Механизм аналогичен предыдущему и имеет ту же иерархию. В случаях, когда проблема является общей, информация об инцидентах, связанных с ней, поступает по аварийному каналу связи («технические проблемы со связью»).
3.6 Данные о процессе поддержки ПО
Данные о персонале, задействованном в процессе поддержки, приведены в главе 4.
Возможные технические и программные неисправности на стороне Заказчика исправляются в рабочее время одним из специалистов поддержки. В сложных случаях привлекаются разработчики или системный администратор офиса, по договоренности с руководителем. В нерабочее время неисправности устраняются одним из специалистов поддержки или системным администратором офисов.
3.7 Порядок взаимодействия службы поддержки ПО с заказчиком
Получение жалоб и пожеланий заказчика:
Периодическое:
o Опрос заказчика в определенные периоды по электронной почте и телефону (ежемесячно)
o Сбор данных и решение вопросов совместимости по электронной почте и телефону при выходе плановых обновлений и патчей ПО (по мере выхода обновлений)
Непериодическое:
o Сбор отзывов персонала Заказчика о ПО по электронной почте (регулярно, круглосуточно)
o Сбор данных и решение вопросов совместимости по электронной почте и телефону при выходе новых версий ПО или существенных обновлений для устранения обнаруженных Заказчиком ошибок
o Сбор данных и решение вопросов совместимости по электронной почте и телефону при обновлении Заказчиком аппаратной базы или ОС
Аварийное:
o Взаимодействие с Заказчиком при возникновении аварийной ситуации, по электронной почте, телефону или с выездом специалиста, по согласованию с Заказчиком
Обработка жалоб персоналом:
Сообщение заказчика заносится в систему bitrix24, где его статус меняется по мере устранения проблемы и сохраняется как «решенная проблема» после устранения. В процессе устранения задействуется как сервисный специалист, имеющий навыки системного администратора и минимальные навыки разработчика, так и специалисты разработки системы при необходимости, согласно этапам п. 3.1-3.5.
3.8 Возможные ошибки
Отсутствие связи с аппаратной частью
4.Требования к персоналу
4.1 Персонал, обеспечивающий техническую поддержку и модернизацию
Общие требования к специалистам, обеспечивающим техническую поддержку, интеграцию и развитие «Тестер изделия "Барьер"» на первой линии поддержки:
Знание функциональных возможностей программы
Знание API «Тестер изделия "Барьер"» и настроек каналов связи с аппаратной частью
Знание функционала и настроек операционных систем Windows и Linux.
Общие требования к специалистам, обеспечивающим техническую поддержку, интеграцию и развитие «Тестер изделия "Барьер"» на второй линии поддержки:
Знание функциональных возможностей информационной системы
Знание API «Тестер изделия "Барьер"» и настроек каналов связи с аппаратной частью.
Знание аппаратной части.
Знание функционала и настроек операционных систем Windows и Linux.
Общие требования к специалистам, обеспечивающим техническую поддержку, интеграцию и развитие «Тестер изделия "Барьер"» на первой линии поддержки:
Знание функциональных возможностей информационной системы, архитектуры и программного кода, и пользовательского интерфейса
Знание API «Тестер изделия "Барьер"» и настроек каналов связи с аппаратной частью.
Знание функционала и настроек операционных систем Windows и Linux.
4.2 Уровень подготовки пользователя
Пользователь «Тестер изделия "Барьер"» должен иметь опыт работы в операционных системах Windows и Linux с программами подобного типа.
Пользователь должен знать аппаратную часть, её функциональность и назначение.
Для работы с «Тестер изделия "Барьер"» пользователю необходимо изучить руководство пользователя.
4.3 Данные о персонале, задействованном в процессе разработки (количество, квалификация)
Данные о персонале, задействованном в процессе разработки ПО приведены в таблице ниже:
ФИО Должность Образование Специальность
Азизов Олег Али-Аскерович Программист разработчик Высшее техническое Ведущий разработчик
4.4 Данные о персонале, задействованном в процессе тестирования, отладки и установки ПО (количество, квалификация)
Данные о персонале, задействованном в процессе тестирования, отладки и установки ПО приведены в таблице ниже:
ФИО Должность Образование Специальность
Азизов Олег Али-Аскерович Программист разработчик Высшее техническое Ведущий разработчик
4.5 Данные о персонале, задействованном в процессе поддержки, эксплуатации и модернизации ПО (количество, квалификация)
Данные о персонале, задействованном в процессе поддержки, эксплуатации и модернизации ПО приведены в таблице ниже:
ФИО Должность Образование Специальность
Азизов Олег Али-Аскерович Программист разработчик Высшее техническое Ведущий разработчик
5 Дорожная карта проект (ключевые ближайшие ПОЛГОДА)
1. Обеспечить возможность работы программы с изделиями не только по изернет сети через промежуточные аппаратные средства, но и непосредственно через простой конвертер USB-RS485.
2. Обеспечить протоколирования результатов работы программы с последующим выводом отчёта за заданный период.