Как создать технологическое портфолио?

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

Вопросы технологического портфолио

Контекст вопроса

Первым делом, следует решить следующие задачи:

• Для какой целевой платформы мы разрабатываем продукт?
  Какая это будет операционная система, какой набор библиотек и приложений потребуется дополнительно, чтобы наш продукт запускался и успешно функционировал? Кто-то скажет, что это надо решать ещё на этапе создания маркетинговой спецификации продукта. Соглашусь. В то же время, технологически нам важно знать, какие конкретные версии и релизы сторонних продуктов предполагается использовать, так это прямо влияет на конфигурацию платформы тестирования.
  
• На каком языке программирования и какой версии будет вестись разработка?
  Разумеется, ответ на этот вопрос зависит от ответа на вопрос выше. Но не только от целевой платформы зависит выбор языка. Многое зависит от конкретной прикладной области, для которой предназначен проектируемый продукт.
  От наличия готовых решений третьих производителей, оформленных в виде библиотек, которые можно использовать на тех или иных условиях. Зависит также от квалификации и опыта команды разработчиков и наработанных ей собственных шаблонов. И наконец, это может зависеть от личных предпочтений лидеров проекта. Особенно важен вопрос выбора версии языка. Иногда приходится наступить на горло собственной инженерной песни и сознательно остановиться на более ранней версии, если известно, что только она обеспечит надёжную работу всех тех многообразных модулей, составляющих продукт.
  
• На какой платформе будут работать разработчики?
  К платформе разработки следует отнести не только среду разработки программного кода, которая в общем случае представляет из себя триаду редактор-компилятор-отладчик. Не менее важен вопрос выбора операционной системы, под которой будет функционировать рабочее место разработчика. Назовём её инструментальной. Инструментальная операционная система не обязательно должна совпадать с целевой. Её основная функция заключается в том, чтобы обеспечить надёжное функционирование рабочего места разработчика, в том числе быстродействие, поддержку всех необходимых функций индивидуальной и коллективной работы, обслуживание обновлений.
  Следует решить также вопрос о выборе средств высокоуровневого проектирования программного обеспечения, например, системе создания диаграмм UML. В проекте, где ожидается около 5000 пунктов функциональных требований и задействовано несколько десятков специалистов, без инструментов высокоуровневого проектирования просто не обойтись.
  Размышляя над этим, невольно ловишь себя на мысли – а сколько это всё будет стоить? И это очень хороший вопрос, на который придётся ответить рано или поздно. Управлять стоимостью можно с помощью баланса между платным и бесплатным ПО, что, в свою очередь, требует хорошего понимания ограничений и требований различных видов лицензий.
  
• Каким будет рабочее место сборки продукта?
  Технологический процесс разработки подразумевает, что разработчики работают каждый в своей ветке и в единый продукт они собираются на отдельной машине сборки. Главный вопрос, на который следует ответить при решении этой задачи, это – можно ли собирать проект для одной целевой операционной системы под управлением другой?
  При всей очевидной выгоде такого решения, когда достаточно иметь одно рабочее место сборки для всех типов целевых операционных систем, следует учитывать возможные издержки, связанные с различием версий компиляторов, сборщиков и библиотек, которые используются при сборке, даже внутри одного семейства операционных систем. И если сравнить все плюсы и потенциальные риски, может оказаться, что держать отдельную сборочную машину для каждой целевой платформы будет дешевле. Под машиной будем понимать не только отдельно стоящий железный компьютер, но и виртуальную машину, Docker-контейнер и другие средства виртуализации.
  
• А на какой платформе следует тестировать продукт?
  Здесь, кажется, ответ очевиден – на той, которая максимально близка к целевой.  В то же время, если предполагается эксплуатация на большом количестве версий одного семейства операционных систем – скажем, Windows, – то можно решить вопрос с помощью установки различных пакетов окружения на одной машине.
  
• Какие использовать библиотеки классов и шаблонов?
  Набор библиотек очень сильно зависит от той функциональности, которую мы хотим получить в своём продукте. На начальном этапе трудно в деталях проработать все те функциональные блоки, которые потребуются в процессе разработки продукта, однако опыт подсказывает, что некоторые общие наборы функциональных возможностей присутствуют в каждом проекте.

Функциональные группы

На рисунке приведён примерный перечень функциональных блоков, необходимых для настольного приложения с возможностями коллективной работы, которым является разрабатываемый нашей командой ПОЛАТОР.
Показаны также ожидаемые зависимости между модулями. Из всего многообразия предлагаемых платных и бесплатных библиотек следует выбрать те, которые закроют данные направления и облегчат труд разработчикам.
Применение библиотек в разработке ПО схоже с применением комплектующих изделий при проектировании изделий машиностроения. Автомобиль можно сделать полностью самим, включая те тысячи болтов и гаек и километры проводов, которые ы нём используются. А можно собрать из полностью готовых изделий, приобретённых у других поставщиков. Где-то посередине лежит тот компромисс, который нам нужен.

На что влияет?

Зададимся теперь вопросом, почему выбор технологического портфолио важен и на какие параметры проекта влияет?

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

Применяемые инструменты диктуют требования к квалификации персонала. Например, если мы решили строить пользовательский интерфейс на библиотеке Qt, мы должны понимать, что от разработчиков требуется иметь опыт работы с данной библиотекой. Или примириться с затратами времени на её освоение. И так далее.
Из предыдущего тезиса логично вытекает вывод о том, как технологическое портфолио влияет на сроки проекта. Допустим, мы решили применить библиотеку Qt, но наши разработчики никогда с ней не работали. Это означает, что им потребуется врем на её освоение. Или, допустим, мы решили собирать проект для разных целевых платформ на одной машине. Значит, мы должны учесть риски потерь времени в тех случаях, когда код, собранный для “чужой” платформы, вдруг отказывается на ней работать и нам придётся искать причины несоответствий.