Аутсорсинг и контрактная разработка Windows-приложения: что стоит прояснить перед заказом

Когда рассматривается аутсорсинг или контрактная разработка Windows-приложения, первое, что нужно решить, — это не только «на какой технологии его делать».

На практике мы регулярно получаем такие запросы:

• Хотим доработать старое Windows-ПО
• Не можем принять во владение внутреннее приложение, созданное предшественником
• Связь с оборудованием или измерительным прибором время от времени обрывается
• Задействованы 32-битность / 64-битность, COM / ActiveX и интеграция с VBA
• После перехода на Windows 11 или новый ПК приложение перестало работать
• Хотим разобраться со всем сразу: развёртыванием, подписью кода, автообновлениями и предупреждениями SmartScreen
• Хотим расследовать сбои или рост потребления памяти после долгой работы

Иными словами, аутсорсинг и контрактная разработка Windows-приложения — это не просто «построить новые экраны». Это нужно рассматривать как работу, включающую обследование существующих активов, доработку, замену, интеграцию с оборудованием, развёртывание, обслуживание и расследование сбоев.

В этой статье с точки зрения заказчика собраны моменты, которые стоит прояснить перед тем, как заказать аутсорсинг или контрактную разработку Windows-приложения.

Области, с которыми чаще всего обращаются к подрядчикам по Windows-приложениям

1. Разработка новой бизнес-логики приложения

Это случаи, когда экраны ввода, экраны поиска, вывод отчётов, интеграция с CSV, интеграция с файлами и интеграция с внешними системами, поддерживающие внутренние процессы, реализуются как Windows-приложение.

Причины выбрать Windows-приложение вместо веб-приложения обычно сводятся к следующему:

• Нужна тонкая работа с файлами и папками на локальном ПК
• Нужна интеграция с USB-устройствами, измерительными приборами, ПЛК, камерами
• Нужно использовать приложение в офлайн-среде или в закрытой сети
• Нужно задействовать существующие активы Excel, VBA, COM, DLL
• На терминалах на местах нужны клавиатура, сканер штрихкодов, сенсорная панель
• Нужен резидентный мониторинг или фоновая обработка

Даже при разработке с нуля, если заранее решить, должно ли это быть именно Windows-приложение, достаточно ли веб-приложения или лишь часть функционала стоит оставить на стороне Windows, это заметно сократит количество последующих переделок.

2. Доработка и обслуживание существующего Windows-ПО

В запросах на аутсорсинг и контрактную разработку доработка и обслуживание существующего ПО встречаются чаще, чем разработка полностью с нуля.

Например, вот такие ситуации:

• Исходный код есть, но никто не знает, как его собрать
• Открывается только в старой версии Visual Studio
• Проект застрял на VB6, MFC, WinForms или .NET Framework
• Ответственный сотрудник уволился, и никто не знает спецификацию
• После обновления Windows или замены ПК работа стала нестабильной
• Партнёры или сотрудники на местах просят добавить функции

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

• Какой бизнес-процесс поддерживает приложение?
• Какие функции обязательны?
• В какой среде оно работает?
• От каких внешних устройств, DLL, баз данных и общих папок оно зависит?
• Сохранились ли логи и информация об ошибках?
• Сохранились ли исходный код, инструкции по сборке, установщик и файлы конфигурации?

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

Если задействованы COM / ActiveX / OCX, сначала разберитесь с терминологией в статье Подробное объяснение различий между COM, ActiveX и OCX, а стратегию миграции удобнее продумывать с помощью подходов вроде Таблицы решений «сохранить / обернуть / заменить» для ActiveX/OCX — это упрощает движение вперёд.

3. Приложения для интеграции с оборудованием и внешними устройствами

В производстве, контроле качества, измерениях, смежных с медициной областях и научных исследованиях Windows-приложения часто связаны с внешним оборудованием.

Типичные объекты интеграции:

• Устройства последовательной связи
• USB-устройства
• Промышленные камеры
• ПЛК
• Измерительные приборы
• Сканеры штрихкодов
• Общие папки и NAS
• Существующие нативные DLL
• SDK от поставщиков

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

Особенно последовательная связь склонна создавать проблемы с единицами приёма, тайм-аутами, повторным подключением и зависанием интерфейса, поэтому разумно с самого начала учитывать такие моменты, как описано в статье Подводные камни разработки приложений с последовательной связью.

Кроме того, состояния внешнего устройства иногда недостаточно описывать только как «подключено» или «не подключено». Если отдельно учитывать наличие устройства, отклик, готовность функций, актуальность данных и соответствие конфигурации, получится экран, который сложнее неправильно понять на месте. Подробнее об этом — в статье Проектирование отображения состояния внешних устройств.

4. Расследование ошибок и анализ причин

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

Часто встречаются такие запросы:

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

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

При расследовании сбоев ключевое значение имеет то, как сохранить свидетельства именно в момент сбоя, как описано в статьях Как логировать сбои Windows-приложения и Введение в сбор дампов сбоев (WER/ProcDump/WinDbg).

При проблеме роста памяти нужно различать, идёт ли речь просто об ожидании сборщика мусора или о настоящей утечке памяти. Для .NET-приложений применяется процедура наблюдения, сравнения и доказательства, описанная в статье Как отличить ожидание GC от утечки памяти в .NET.

5. Развёртывание, подпись и автообновления

Готовое Windows-приложение часто спотыкается именно на вопросе «как его распространять».

• Делать ли установщик?
• Или достаточно просто разложить файлы, чтобы всё заработало?
• Смогут ли установить его стандартные пользователи?
• Требуются ли права администратора?
• Распространять через внутренний файловый ресурс?
• Или пользователи будут скачивать его из веба?
• Нужны ли автообновления?
• Как обращаться с сертификатом подписи кода?
• Как объяснять и обрабатывать предупреждения SmartScreen?

Способы развёртывания включают MSI, MSIX, ClickOnce, xcopy и собственные обновители. Выбор должен опираться не на «что проще», а на то, что регистрируется в ОС и кто несёт ответственность за обновления. Подробнее об этом в статье Руководство по выбору способа развёртывания Windows-приложений.

Для внутреннего .NET Windows-приложения, которое нужно распространить среди стандартных пользователей с лёгкими автообновлениями, полезна статья Введение в ClickOnce: развёртывание, обновления и критерии выбора.

С другой стороны, при распространении через веб или за пределами компании возникают вопросы предупреждений SmartScreen и подписи кода. Причина появления сообщения «Windows защитила ваш компьютер» разобрана в статье Почему Windows показывает «Windows защитила ваш компьютер».

Пять вещей, которые стоит прояснить перед заказом аутсорсинга или контрактной разработки Windows-приложения

1. Что не должно останавливаться

В первую очередь нужно прояснить не список функций, а «бизнес-процессы, остановка которых недопустима».

• Останавливается обработка заказов
• Останавливается линия контроля качества
• Невозможно сформировать отчёты
• Прерывается связь с оборудованием
• Персонал на местах вынужден переходить на ручную работу
• Не сохраняются аудиторские следы

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

2. Текущее приложение и окружающая среда

При доработке и обслуживании существующего приложения проверяется не только само приложение, но и окружающая среда.

Информация, которую стоит зафиксировать:

• Название приложения, назначение, использующие подразделения
• Количество пользователей и количество машин
• Версии Windows
• 32-битность / 64-битность
• Версии .NET Framework / .NET
• Версия Visual Studio
• Базы данных, общие папки, внешние API
• Интегрированные устройства, DLL, SDK
• Процедура установки
• Расположение файлов конфигурации
• Расположение логов
• Наличие исходного кода
• Наличие инструкций по сборке
• Наличие материалов, оставленных предшественником

Чем полнее эта информация, тем точнее оценка стоимости и результаты обследования. И наоборот, если информации не хватает, безопаснее выделить первый этап отдельно как «обследование текущего состояния».

3. Разработка с нуля, доработка или замена?

В запросах по Windows-приложениям зачастую лучше не решать сразу «переписать заново».

Стоит ли продолжать использовать приложение на .NET Framework или переходить на .NET, зависит от типа приложения, зависимых библиотек, интеграции с COM и способа развёртывания. Заранее провести инвентаризацию пунктов проверки, как в статье Чек-лист перед миграцией с .NET Framework на .NET, значительно облегчает решение.

4. Развёртывание, обновления и права

В Windows-приложениях иногда затыком становится не разработка, а именно развёртывание.

Особенно стоит уточнить следующие моменты:

• Будут ли использовать стандартные пользователи?
• Есть ли операции, требующие прав администратора?
• Установка для всех пользователей или достаточно на уровне пользователя?
• Только внутреннее использование или также распространение вовне?
• Нужны ли автообновления?
• Есть ли офлайн-машины?
• Требуется ли подпись кода?
• Нужно ли учитывать Microsoft Defender SmartScreen?
• Есть ли политики управления вроде Intune, GPO или App Control?

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

5. Удобство сопровождения

В контрактной разработке важно не только то, что приложение работает на момент сдачи. Хочется, чтобы даже спустя годы другой ответственный сотрудник мог его обследовать, дорабатывать и повторно развёртывать.

У Windows-приложений, удобных в сопровождении, есть такие черты:

• Сохранены инструкции по сборке
• Известны зависимые библиотеки и их версии
• Известны расположение и назначение файлов конфигурации
• Логи выводятся с детализацией, достаточной для расследования
• При сбое сохраняются свидетельства
• Есть процедуры развёртывания и отката
• Ответственность в исходном коде чётко разделена
• Операции, требующие прав администратора, ограничены
• Секретная информация не хранится в открытом виде

Для минимальной проверки безопасности перед релизом проверяются права, подпись, секретная информация, связь, ввод данных, DLL и логирование — как в статье Чек-лист безопасности Windows-приложений.

Если пароли или токены хранятся в файлах конфигурации, нужно избегать хранения в открытом виде и проектировать защиту с использованием механизмов Windows. Подробнее об этом в статье Как безопасно хранить секретные данные в файлах конфигурации.

Частые технологические решения для Windows-приложений

Выбор между WinForms, WPF и WinUI

При разработке нового Windows-приложения регулярно встаёт вопрос, что использовать — WinForms, WPF или WinUI.

В общих чертах сравнение выглядит так:

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

Подробнее об этом — в виде таблицы решений в статье Руководство по выбору WinForms/WPF/WinUI.

Достаточно ли C# / .NET, или нужны C++ и нативные DLL?

Большинство бизнес-приложений можно полностью реализовать на C# / .NET. Однако в случаях вроде следующих иногда рассматривают C++, нативные DLL, P/Invoke, C++/CLI и COM:

• SDK поставщика ориентирован на C/C++
• Нужно вызывать существующие DLL
• Требуется высокоскоростная обработка изображений или управление устройствами
• Нужно использовать существующие активы COM
• Нужно пересекать границу 32-битности / 64-битности

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

Windows-приложение или веб-приложение?

Мы также получаем запросы вроде «хотим перевести старое Windows-приложение в веб». Иногда переход в веб оправдан, но переводить в веб абсолютно всё не обязательно.

Windows-приложение подходит, например, в таких случаях:

• Прямое подключение к оборудованию или локальным устройствам
• Использование в офлайне
• Работа с крупными локальными файлами
• Использование существующих активов COM / DLL / VBA
• Необходимость быстрой работы на терминалах на местах
• Резидентный мониторинг и фоновая обработка

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

На практике вместо переноса всего в веб сразу существуют и архитектуры, при которых сохраняется только та часть, которой действительно нужно Windows-приложение, а управление и просмотр данных выносятся на веб-сторону.

Как проходит контрактная разработка

Аутсорсинг и контрактную разработку Windows-приложения безопасно вести в таком порядке.

1. Обследование текущего состояния

Сначала определяются целевой бизнес-процесс, среда использования, существующее приложение, внешнее оборудование, способ развёртывания и симптомы проблем.

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

2. Проектирование точек наблюдения

При наличии ошибок или нестабильности причину сначала делают отслеживаемой, а не сразу переходят к исправлениям:

• Добавляется логирование
• Собираются дампы сбоев
• Сохраняются логи связи
• Фиксируются память и количество хэндлов
• Сохраняется история операций
• Сохраняются скриншоты и состояние в момент сбоя

Чем труднее воспроизвести проблему, тем сильнее окупается проектирование точек наблюдения.

3. Определение стратегии

Изучив текущее состояние, определяют стратегию: доработка, продление жизни, поэтапная миграция, полная замена или только расследование ошибок.

На этом этапе также определяются выбор технологии, способ развёртывания, способ обновления и объём сопровождения.

4. Реализация и тестирование

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

При тестировании проверяются не только штатные сценарии, но и нештатные:

• Устройство не подключено
• Связь обрывается посреди сеанса
• Файл заблокирован
• Недостаточно прав
• Сеть нестабильна
• Конфигурация повреждена
• Обновление завершается ошибкой
• Приложение аварийно завершает работу

5. Развёртывание и миграция

После завершения готовятся процедуры развёртывания, обновления, отката, начальная конфигурация и разъяснения для пользователей.

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

6. Сопровождение и улучшение

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

Windows-приложения подвержены влиянию обновлений ОС, замены ПК, изменений периферии и изменений политики безопасности. Именно поэтому проектирование и документирование с расчётом на сопровождение незаменимы.

Информация, которую полезно подготовить перед оценкой стоимости

К моменту консультации не обязательно иметь всё готовым. Однако наличие следующей информации заметно ускоряет обсуждение:

• Назначение приложения
• Что сейчас вызывает проблемы
• Количество пользователей и машин
• Версии Windows
• Наличие существующего приложения
• Наличие исходного кода
• Язык разработки и фреймворк
• Интегрированные устройства, базы данных, файлы, API
• Экраны ошибок и логи
• Шаги воспроизведения
• Желаемый срок сдачи
• Бизнес-процессы, остановка которых категорически недопустима
• Внутреннее или внешнее распространение
• Нужно ли также сопровождение

Ничего страшного, если какие-то пункты неизвестны. Прояснить, что известно, а что нет, — это и есть первая задача контрактной разработки.

Итоги

При заказе аутсорсинга или контрактной разработки Windows-приложения простая фраза «сделайте нам приложение» не даёт разглядеть необходимый объём работ.

Вот 7 пунктов, которые стоит прояснить перед заказом:

• Разработка с нуля, доработка существующего или замена?
• Какие бизнес-процессы не должны останавливаться?
• Есть ли существующие активы, внешнее оборудование, DLL, COM, ActiveX?
• Выбор технологии: WinForms, WPF, WinUI, миграция на .NET и так далее
• Как обращаться с развёртыванием, подписью, автообновлениями и правами администратора?
• Проектирование расследования по логам, дампам сбоев, памяти и связи
• Как оставить приложение в сопровождаемом состоянии после сдачи?

Windows-приложения тесно связаны с бизнес-процессами на местах, оборудованием, файлами, периферией и ограничениями операционной системы Windows. Именно поэтому в аутсорсинге и контрактной разработке важно проектировать не только «строительство», но и «расследование», «исправление», «документирование», «распространение» и «эксплуатацию».

Если вас беспокоят вопросы аутсорсинга или контрактной разработки Windows-приложения, разработки с нуля, доработки и обслуживания существующего ПО, интеграции с оборудованием, расследования ошибок или проектирования развёртывания и обновлений, начните с обращения к нам, чтобы прояснить текущую ситуацию.

Обратиться по разработке Windows-приложений

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

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

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

Можно ли обратиться к вам, даже если исходного кода нет?

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

Можно ли обратиться к вам по приложению со старым VB6, VBA, COM или ActiveX?

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

Стоит ли заменить наше Windows-приложение веб-приложением?

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

Можно ли заказать только расследование ошибки?

Да, можно. При сбоях после долгой работы, обрывах связи, росте потребления памяти или неполадках, которые проявляются только на отдельных ПК, важно сначала сделать причину отслеживаемой, а не сразу переходить к исправлениям. Мы приводим в порядок логи и дампы, сужаем условия воспроизведения и только потом определяем стратегию исправления.

Можете ли вы разрабатывать приложения, требующие прав администратора?

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

Можете ли вы разрабатывать по контракту небольшие внутренние Windows-приложения?

Да. Даже для небольших приложений заранее продуманные развёртывание, обновления, логирование, конфигурация, резервное копирование и передача дел между ответственными делают их удобными в использовании на долгий срок. В частности, для небольших улучшений процессов — автоматизации работы с Excel, конвертации CSV, слежения за файлами, вывода отчётов, сбора данных с оборудования — Windows-приложение часто оказывается удачным выбором.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

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