Чей должен быть код для программного обеспечения, которое вы печатаете?

Рабочий экран и поставляемый продукт — не одно и то же.

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

Данная статья не определяет правового результата договора. Объем прав оценивается в соответствии с соглашением, используемыми компонентами и применимым законодательством. При необходимости ознакомьтесь с условиями договора с экспертом по правовым вопросам. Единственное, что можно сделать технически, — это перевести ожидаемый результат в понятный список. Какая часть разработана специально для вас, какая используется как готовый сервис, а какая основана на сторонней библиотеке? Без этого различия предположение, что весь код будет доставлен с одинаковыми условиями, может ввести в заблуждение.

Определяет нужную вам модель доставки

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

Запрошенная поставка должна быть совместима с объемом проекта. Например, когда вы получаете написанные для вас экраны приложения, вы не можете использовать внутреннее программное обеспечение облачного сервиса. Однако вы можете захотеть документировать, какие данные были отправлены в эту службу и как было установлено соединение. Вместо того, чтобы предполагать, что поставка, не включенная в предложение, произойдет автоматически позже, уточните вопрос письменно.

Какую информацию следует указывать рядом с кодом?

Хорошее начало — наличие исходных файлов в папке; одного недостаточно для устойчивого развития. Какая версия кода активна, какой инструмент разработки используется и как исправляются версии зависимостей? Имена переменных конфигурации, их значения экземпляров и безопасный метод предоставления должны быть задокументированы. Фактические пароли или ключи не следует размещать в хранилище кода. Новая команда должна иметь возможность установить приложение, получив секреты в рамках отдельного авторизованного процесса. Четкое указание конфиденциальной информации о производственной среде в документе о доставке не облегчает доставку; создает новый риск.

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

Отдельные зависимости и условия использования.

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

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

Проверьте доставку небольшим приемочным испытанием.

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

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

Частые вопросы

Достаточно ли получить исходный код?

Нет. Также требуются установочная документация, зависимости, правильные условия использования и проверка работы в чистой среде.

Ожидается ли доставка кода в каждом программном обеспечении?

Модель доставки готового сервиса подписки и программного обеспечения, разработанного специально для вас, может отличаться. Четко определите модель и объем в контракте.

Как проверить смену поставщика?

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