Критерии качества
Наша команда специализируется на контрактной разработке программного обеспечения и электроники. Обеспечение качества (QA) применяется на всех этапах разработки продукта, чтобы максимально исключить потенциальные ошибки. При этом сам заказчик не обязательно является конечным пользователем. Конечно, мы стараемся сделать продукт удобным и для потребителя, однако если работу принимает не потребитель, а заказчик, то нам не подойдут такие критерии оценки, как удовлетворенность конечного пользователя. Критериями качества для нас является соответствие продукта требованиям, указанным в техническом задании:
- Функциональные требования — что делает продукт. Критерий оценки здесь — выполняет ли ПО нужную функцию.
- Нефункциональные требования — как работает продукт, например, насколько быстро или точно. Критерий оценки — работает ли ПО так, как указано в требованиях.
В зависимости от характера проекта учитываются и другие критерии: сертификационные требования, возможность и стоимость серийного производства. Таким образом, с точки зрения заказчика, качественный продукт соответствует функциональным и нефункциональным требованиям, легко сертифицируется, легко сопровождается, подходит для массового производства, а также дает минимальное количество возвратов и отказов. С точки зрения конечного пользователя, качественный продукт не сбоит, работает долго, защищен от воздействий окружающей среды и даже от неправильной эксплуатации. Эти моменты мы тоже учитываем.
Как мы обеспечиваем качество при разработке программных продуктов
- Архитектура ПО
При работе над программным обеспечением, будь то прошивка или приложение, большое внимание мы уделяем проработке его архитектуры. Чем она прозрачнее и проще, тем меньше логических ошибок будет допущено и тем выше качество решения.
- Выбор инструментов разработки
Мы стараемся выбирать инструменты и принципы разработки, которые минимизируют вероятность и количество ошибок. Например, почти все проекты сейчас мы выполняем на языке С++, так как он надежнее с точки зрения безопасной работы с памятью и указателями. В результате мы чаще имеем дело с логическими ошибками в программном коде, чем с чисто «программистскими» ошибками.
Так, в рамках одного из наших давних проектов нам поручили создать банковский веб-сервис. Мы проанализировали задачу и поняли, что, используя привычные нам инструменты, мы бы столкнулись с очень большими трудозатратами. Стоимость проекта грозилась заметно вырасти, что вряд ли понравилось бы заказчику. К тому же из-за сложности разработки мы бы неизбежно столкнулись со множеством багов.
Поэтому решено было создавать продукт на платформе Jmix. Во-первых, она позволяет на очень высоком уровне управлять схемами данных. Во-вторых, у Jmix есть встроенный инструментарий для создания вполне приличных графических интерфейсов. Наконец, в ней есть инструменты для работы с REST API.
Выбор этого инструмента позволил ускорить разработку и снизить количество багов. Этот опыт мы запомнили и теперь рассматриваем Jmix как один из возможных инструментов разработки для новых проектов.
- Сборка исходного кода
Современные компиляторы сообщают о разных типах ошибок: явные ошибки, предупреждения и информационные сообщения. Последние два типа далеко не всегда говорят о наличии серьезных проблем. Однако мы подходим к сборке исходного кода с некоторой… паранойей. Мы стараемся проверить и устранить все виды ошибок, чтобы компилятор не выдавал вообще никаких сообщений.
Компилировать код приходится часто — для промежуточных тестов, демонстрации заказчику или других целей. И здесь важно отслеживать, из какой версии исходного кода была собрана программа. Для этого разработчики придерживаются принципов CI/CD и используют серверы сборки. Так, при обнаружении бага мы будем знать, где искать его в исходном коде, а также какую версию мы передали заказчику для тестирования.
- Регулярный Code Review
Когда разработчик завершает свою задачу, его работа сливается с какой-то общей веткой, а написанный им код используется остальной командой на следующих этапах работы. Но сперва его должен просмотреть технический руководитель проекта, чтобы убедиться, что решение оптимально, не приводит к запутанности кода и не затруднит дальнейшую разработку. Это позволяет избежать накопления ошибок.
- Внутренняя документация
Важно вести внутреннюю документацию, где отражаются основные технические особенности проекта, требования к продукту, всевозможные неочевидные детали. Тестовую документацию следует составлять параллельно с разработкой, не дожидаясь ее завершения. Кроме того, тестировщик проверяет всю документацию — в первую очередь полноту требований с точки зрения проверки результатов.
- Документация для заказчика
Продукт нуждается в сопровождении, поэтому относящаяся к нему документация тоже определяет его качество. Ведь заказчик будет продавать созданное решение или интегрировать его в существующую систему. А значит, мы должны предоставить ему инструкции по сборке, информацию по сервисным операциям — в зависимости от проекта. Если заказчик сможет пользоваться решением, не обращаясь к нам за помощью, значит, решение получилось качественным.
Как мы обеспечиваем качество своих IT-продуктов при разработке электроники на заказ
- Сбор требований
Поскольку качество продукта определяется его соответствием требованиям, мы уделяем большое внимание сбору этой информации. Проблема в том, что клиент может не упомянуть что-то, что ему покажется незначительным или очевидным. Поэтому мы тщательно опрашиваем заказчика, стараясь выяснить все возможные детали, даже те, которые могут показаться малозначимыми.
- Выбор компонентной базы
При разработке электроники на качество будущего изделия влияет непосредственно выбор компонентов. Если при прочих равных у одного варианта характеристики лучше, чем у другого, мы выбираем первый. Например, у нас два транзистора с рассеиваемой мощностью 4 и 0,5 Вт. Второй греется меньше, чем первый, а значит, обеспечит большую надежность и более высокое качество продукта. Это, разумеется, если позволяет бюджет.
Предпочтение отдаем компонентам, которые уже имеют те или иные сертификации, подтверждающие их качество.
- Документация к компонентам
Когда мы работаем с каким-то компонентом впервые, мы тщательно изучаем документацию к нему. Если это ключевой компонент, без проверки которого в дальнейшей разработке нет смысла, или если позволяют бюджет и время, мы также заказываем опытные образцы для тестирования. Дело в том, что, если у продукта есть проблемы, производители не горят желанием писать об этом крупным шрифтом.
Так, в одном проекте мы решили использовать LTE-модуль со встроенной функцией спутникового геопозиционирования. В документации к модулю было сказано, что он может выполнять обе функции, но не сказано, что использовать их одновременно нельзя. Об этом сообщил разработчик модуля, когда мы с ним связались.
Наученные горьким опытом, теперь мы внимательно изучаем документацию, тестируем образцы или проясняем такие моменты напрямую у производителей компонентов.
- Качество проектирования
Один и тот же функционал можно воплотить в жизнь по-разному. И речь не столько о разных подходах к решению задачи, сколько об учете банальных законов физики при проектировании печатной платы. Если по одной из дорожек предполагается пустить большой ток, то дорожка должна быть достаточно большой, иначе выгорит. Это, казалось бы, очевидные вещи, но качество продукта определяют в том числе и такие банальности.
- Принципы DFM
Если создаваемое изделие предполагается запустить в серийное производство, при разработке необходимо придерживаться принципов Design for Manufacturing (DFM), то есть разработки с учетом требований производства.
Для этого команда старается сделать устройство простым и подходящим для стандартных производственных процессов, подбирать доступные компоненты, которые есть на рынке в достаточном количестве.
- Особенности эксплуатации
Любое устройство должно служить как можно дольше. Для этого нужно учитывать условия, в которых его предполагается использовать.
Самое банальное, что здесь можно сделать, — это разместить греющиеся элементы ближе к вентиляционным отверстиям или под радиатором. Также часто ставится защита от электромагнитных помех. Если устройство должно функционировать во влажной среде, плату либо заливают компаундом, либо покрывают лаком. Добиться высокого качества позволяют избыточные решения — например, защита от переполюсовки, если устройство имеет батарейное питание.
- Прототипирование
Если перед нами стоит нетривиальная задача, сначала мы проверяем предлагаемые решения на работоспособность. Для этого создается прототип. Как правило, он делается с помощью комплектов разработчиков, то есть собирается «на коленке», что дешевле проектирования полноценной платы.
Может показаться, что это лишняя работа, но так мы можем определить оптимальное решение еще до того, как изменения станут слишком затратными по времени и по деньгам.
Проводим фиксацию удачного и неудачного опыта после работы над проектами
Даже после разработки команда стремится вынести уроки из удачных и неудачных решений, чтобы не повторять таких ошибок в будущем. Например, мы проводим встречи участников команды после завершения проекта для подведения итогов. На них мы говорим об удачах и неудачах, о том, какие возникли проблемы и почему. Самое важное фиксируется в базе знаний компании в виде правил, принципов, рекомендаций по выбору и работе с инструментами, порядку выполнения задач и т. п.
Например, в нашей базе знаний есть пункт, гласящий, что если вы столкнулись с проблемой и не можете ее решить, не стесняйтесь рассказать об этом коллегам и руководителю. Появился он там после одного случая. Один из разработчиков закопался в проблему и никак не мог ее решить. Потратил он на это почти 40 часов, а на проект было выделено всего 100 часов. В итоге мы сорвали сроки и превысили бюджет. А всё потому, что разработчик побоялся признаться, что не справляется.
Также мы фиксируем опыт работы с компонентами того или иного производителя. А всё потому, что у нас был неудачный опыт. Мы поставили на плату китайский микроконтроллер с объемом памяти 2 МБ. Но впоследствии выяснилось, что память у него состоит из двух чипов и фактически разделена на две части — быструю и медленную. Соответственно, прошивка в одной части выполнялась в несколько раз медленнее, чем в другой. Таких подробностей в документации к микроконтроллеру не указали. Поэтому теперь при работе с китайскими производителями мы обращаем внимание на такие детали.
Фиксация удачного и неудачного опыта, конечно, не исправит текущий проект, но позволит избежать повторения аналогичных ошибок в будущем. Так формируются внутренние стандарты работы над проектами, которые играют важную роль в повышении качества IT-продукта.
Те, кто не связан со сферой IT, обычно думают, что сначала команда разрабатывает продукт, а затем его тестирует. Если всё в порядке, разработка идет на рынок или в эксплуатацию. Если что-то не так, продукт дорабатывается. Однако если ограничиться одним лишь тестированием, создание IT-продукта станет слишком дорогим. Много внимания уделяется различным аспектам разработки как до, так и во время самого процесса. Без системного подхода к разработке испытания будут выявлять всё новые и новые ошибки, а их исправление будет занимать недели и месяцы.
