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

​Оглавление 

• Аннотация
• Описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения Picvario
• Устранение неисправностей, выявленных в ходе эксплуатации программного обеспечения Picvario
• Совершенствование программного обеспечения Picvario
• Информация о персонале, необходимом для обеспечения поддержки жизненного цикла программного обеспечения Picvario

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

Описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения Picvario

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

1. Контроль, планирование и сбор требований по изменениям в программном обеспечении;
2. Разработка новых и доработка существующих функций программного обеспечения на основании требований по изменениям;
3. Тестирование всех изменений программного обеспечения, при выявлении несоответствия изменений сформулированным требованиям – направление изменений на доработку;
4. Развертывание изменений на production-серверах, что обеспечивает доставку изменений в программном обеспечении пользователям;
5. Поддержка работоспособности программного обеспечения, клиентская поддержка;
6. Документирование всех требований, функций и разработок программного обеспечения.

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

Процесс тестирования состоит из следующих шагов: определение типа тестирования, фиксация багов, фиксация дефектов, составление документации.

Выделяются и проводятся следующие виды тестирования программного обеспечения:

• Функциональное тестирование — тестирование заранее указанного поведения, основыванное на анализе функциональных требований и спецификаций компонента или системы в целом;
• Тестирование интерфейса, которое включает в себя тестирование верстки на соответствие макетам, тестирование верстки на различных разрешениях экрана и тестирование кроссбраузерности (проверка на поддержку и правильное полное отображение программного обеспечения в разных браузерах, мобильных устройствах, планшетах, смартфонах, экранах различного размера);
• Интуитивное тестирование — вид тестирования, который выполняется без подготовки к тестам, без определения ожидаемых результатов, проектирования тестовых сценариев, т.е. как неформальное, импровизационное тестирование;
• Исследовательское тестирование — вид тестирования, который может быть описан как «продвинутое» интуитивное тестирование, при котором в действиях тестировщика присутствует логика, основанная на всей информации о проекте, а также подразумевает формирование плана тестирования и тестов без их фиксации в документации.

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

Основными принципами тестирования являются:

• Тестирование демонстрирует наличие дефектов. Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, это не доказывает его корректности.
• Исчерпывающее тестирование недостижимо. Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.
• Раннее тестирование. Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения или системы, и должны быть сфокусированы на определенных целях.
• Скопление дефектов. Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей.
• Парадокс пестицида. Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот «парадокс пестицида», тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.
• Тестирование зависит от контекста. Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции.
• Заблуждение об отсутствии ошибок. Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.

В результате проведения тестирования появляются следующая документация:

• Баг или дефект репорт – это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата;
• Тестовый сценарий (Test Case) – это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части;
• Набор тестовых сценариев – это тестовые сценарии, сгруппированные по некоему признаку (например, тестируемой функциональности);
• План предварительных испытаний – это документ, в котором указывается следующая информация: объекты испытаний, функциональные характеристики, подлежащие испытаниям, цель испытаний, требования к системе, требования к документации, перечень тестовых сценариев по отдельным программным модулям;
• Протокол выполнения предварительных испытаний – это документ, в котором указывается следующая информация: объекты испытаний, цель испытаний, результаты испытаний;
• План приемочных испытаний – это документ, в котором указывается следующая информация: объекты испытаний, функциональные характеристики, подлежащие испытаниям, цель испытаний, требования к системе, требования к документации, средства и порядок испытаний, методы испытаний, перечень высокоуровневых тестовых сценариев.

Среди принципов при разработке программного продукта можно выделить:

• Адаптивная верстка с применением подхода Mobile First.
• Применение подхода Pixel Perfect при верстке.
• Использование SVG где это возможно.
• Использование Sass для стилей.
• Отказ от сторонних CDN для ассетов.
• Использование структуры БЭМ (Блок, Элемент, Модификатор): интерфейс делится на блоки, которые друг от друга не зависят. Блок можно вынести отдельно или куда-то переместить, и он сохранит свой внешний вид. Блок — независимая сущность со своим собственным значением, представляющая из себя кусочек интерфейса страницы. Элемент — это часть блока, которая привязана к нему семантически и функционально, вне блока элемент смысла не имеет. Модификаторы — это флаги состояния.
• Работа с системой контроля версий Git, которая помогает поддерживать порядок в изменениях, которые команда вносит в код проекта.

Среди требований к подготовке документации можно выделить следующие:

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

Этапы разработки документации:

• создание структуры документа;
• заполнение структуры документа
• проверка и вычитывание документа.

Основными видами ошибок при составлении документации являются: орфографические, пунктуационные, синтаксические, смысловые. Способы избегания ошибок:

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

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

Устранение неисправностей, выявленных в ходе эксплуатации программного обеспечения Picvario

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

• Срочное устранение неисправности (hotfix) и развертывание исправлений на production-серверах до выпуска следующей версии программного обеспечения Picvario;
• Включвение неисправности в список задач (backlog) для выполнения в рамках выпуска следующей версии программного обеспечения Picvario;
• Единичная работа специалиста службы технической поддержки по запросу пользователя на портале технической поддержки.

Совершенствование программного обеспечения Picvario

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

Совершенствование программного обеспечения Picvario направлено на решение следующих задач:

• Расширение функционала программного обеспечения;
• Улучшение пользовательского опыта взаимодействия с программным обеспечением, в том числе улучшение пользовательского интерфейса и дизайна программного обеспечения;
• Исправление дефектов в работе программного обеспечения;
• Оптимизация нагрузки программного обеспечения на вычислительные мощности, увеличение скорости и стабильности работы программного обеспечения.

Пользователь может самостоятельно повлиять на совершенствование продукта, заполнив форму обратной связи на странице https://support.picvario.com/hc/ru/requests/new, либо отправив письмо на адрес support@picvario.com.

Информация о персонале, необходимом для обеспечения поддержки жизненного цикла программного обеспечения Picvario

Можно выделить следующие категории пользователей программного обеспечения Picvario:

1. Конечный пользователь,
2. Администратор ПО.

Конечный пользователь Picvario должен обладать навыками работы с персональным компьютером на уровне «пользователь», иметь навыки работы с Интернет-браузером и файловой системой персонального компьютера. Справочный центр по работе с программным обеспечением Picvario с подробными инструкциями использования представлен на странице https://support.picvario.com/hc/ru. Техническую поддержку по работе с Picvario конечный пользователь может получить, заполнив форму обратной связи на странице https://support.picvario.com/hc/ru/requests/new, либо отправив письмо на адрес support@picvario.com.

Администратор ПО должен владеть навыками работы с персональным компьютером на уровне уверенного пользователя, иметь знания функциональных возможностей программного обеспечения Picvario. Справочный центр по работе с программным обеспечением Picvario, включая подробное описание возможностей и инструментов Picvario, предоставляемых для администраторов системы, представлен на странице https://support.picvario.com/hc/ru. Техническую поддержку по администрированию Picvario администратор ПО может получить, заполнив форму обратной связи на странице https://support.picvario.com/hc/ru/requests/new, либо отправив письмо на адрес support@picvario.com.