Стадии жизненного цикла

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

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

1.1. Восемь стадий

1. Планирование
2. Разработка
3. Тестирование
4. Демонстрация и подтверждение
5. Внедрение и эксплуатация
6. Совершенствование продукта
7. Сбор и устранение неисправностей
8. Вывод из эксплуатации

Стадии 1–5 повторяются для каждой выпускаемой версии; стадии 6 и 7 выполняются непрерывно, параллельно с эксплуатацией, и служат основой для планирования последующих версий; стадия 8 касается либо отдельного экземпляра (типографии, прекращающей использование), либо функции, выводимой из продукта.

1.2. Планирование

Решение о создании или изменении функции принимается на основании:

• запросов и замечаний типографий-пользователей, полученных по каналам поддержки, при внедрении или от закреплённого менеджера;
• опыта собственной эксплуатации: разработчик сам является типографией и ежедневно использует платформу на реальных заказах, поэтому проблема в рабочем процессе прежде всего ощущается на собственном производстве;
• развития рынка web-to-print и электронной торговли (платежи, доставка, ожидания конечных клиентов), а также предложений конкурентов;
• изменений законодательства и внешних поставщиков (НДС и выставление счетов, защита данных, интерфейсы платёжных провайдеров, курьерских служб и почтовых сервисов), которые имеют приоритет перед улучшениями;
• потребностей безопасности и обновления базовых компонентов.

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

1.3. Разработка

1. Детальный анализ изменения: какую задачу оно решает, кого затрагивает (конечного клиента, менеджера, оператора, бухгалтера), какие экраны и какие данные изменяются, каким образом сохраняют силу существующие данные — старый заказ должен открываться и читаться после обновления точно так же.
2. Реализация в среде разработки, отделённой от эксплуатации, в собственной рабочей ветви кода, под управлением версиями: каждое изменение имеет автора, дату и описание и может быть отменено.
3. Рецензирование изменения до включения в основную ветвь: корректность, безопасность, совместимость, читаемость.
4. Обновление документации и переводов (румынский, русский, английский) для любого изменения, видимого в интерфейсе, — вместе с кодом, а не после него.

1.4. Тестирование

1. Автоматические тесты, выполняемые при каждом изменении: механизм расчёта цены, правила для макетов, серверные проверки, а также статическая проверка типов и стиля кода.
2. Ручное функциональное тестирование в среде разработки и в демонстрационном магазине (на условных данных), в поддерживаемых браузерах и на мобильных устройствах.
3. Регрессионное тестирование критических сценариев перед выпуском: каталог → калькулятор → корзина и макет → оформление → оплата в тестовом режиме платёжного провайдера → заказ в панели управления → статусы и уведомления → документы.
4. Проверка миграций данных на копии данных, когда изменение затрагивает их структуру или значение, с заранее подготовленной процедурой отката.

1.5. Демонстрация и подтверждение

Видимые изменения, а также изменения, запрошенные типографией, демонстрируются до выпуска в демонстрационном магазине и демонстрационной панели управления (Живое демо). Замечания собираются, после чего принимается решение: выпуск, доработка или отказ. Когда это возможно, типография, запросившая функцию, подтверждает её на своём реальном случае до того, как функция становится доступной всем пользователям.

1.6. Внедрение и эксплуатация

У этой стадии две стороны.

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

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

1.7. Совершенствование продукта

Совершенствование ведётся непрерывно, на основании замечаний типографий, собственной эксплуатации и развития рынка, согласно процессу, описанному в главе 04.

1.8. Сбор и устранение неисправностей

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

1.9. Вывод из эксплуатации

Прекращение использования типографией. Подписка не имеет минимального срока; по требованию типографии:

1. подтверждается дата прекращения и определяется, какие данные экспортируются;
2. предоставляется экспорт данных — клиенты, заказы, продукты и файлы — в стандартных форматах (CSV, Excel, PDF и сами файлы), до прекращения доступа;
3. прекращается доступ к сайту и к панели управления; домен принадлежит типографии и может быть направлен ею на другой сайт;
4. экземпляр и его данные удаляются из систем разработчика по истечении срока хранения, предусмотренного политикой конфиденциальности; документы, в отношении которых существуют законодательные обязательства по архивированию, остаются у типографии — благодаря экспорту, выполненному на шаге 2.

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

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