Начать бесплатно

Описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения 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.