Почему у одних компаний качество разработки лучше, чем у других? И главное – как оказаться в числе первых? Сегодня мы поговорим о том, как мы обеспечиваем качество разработки IT-продуктов.
Критерии качества
Какой продукт можно назвать качественным? Эффективный, надежный, удобный, безопасный и даже вкусный – в зависимости от типа товара. Но все эти характеристики приписывают товару конечные пользователи. Мы же чаще всего имеем дело с заказчиками, которые конечными пользователями не являются. Поэтому для нас, как разработчиков электроники и ПО, качество продукта определяется его соответствием требованиям, которые указаны в ТЗ:
- Функциональные требования определяют, ЧТО должен делать продукт. Если печатная плата или программа выполняют нужную заказчику функцию, значит, продукт качественный.
- Нефункциональные требования определяют, КАК должен работать продукт. Если продукт выполняет функцию достаточно быстро, точно, безопасно (подставьте нужное), то мы сделали все правильно.
К некоторым проектам предъявляются и другие требования. С точки зрения заказчика, качественный продукт соответствует функциональным и нефункциональным требованиям, легко сертифицируется, легко сопровождается, подходит для массового производства, а также дает минимальное количество возвратов и отказов.
Разумеется, при разработке мы также учитываем очевидные пожелания конечных пользователей. Мы стараемся, чтобы продукт работал долго, не сбоил, не ломался от повышенной влажности или даже неправильной эксплуатации.
Но «суха теория, мой друг». Как же на деле обеспечить качество IT-продуктов? Для этого есть много способов.
Как мы обеспечиваем качество программного обеспечения
1. Архитектура
Надо быть проще! Чем прозрачнее архитектура встроенного ПО или приложения, тем меньше в нем будет логических ошибок.
2. Выбираем инструменты
Важно работать с такими инструментами, которые минимизируют вероятность и количество ошибок.
Как-то раз нам поручили создать банковский веб-сервис. Если бы мы выбрали привычные нам инструменты, мы бы столкнулись с множеством багов, выросли бы трудозатраты и стоимость проекта. За такое заказчик явно не сказал бы «спасибо». Поэтому команда решила создавать продукт на платформе Jmix. Она позволяет управлять схемами данных на очень высоком уровне. Еще в ней есть инструменты для создания графических интерфейсов и работы с Rest API.
Чаще всего мы разрабатываем программы на языке C++, и на то есть причина. С точки зрения безопасной работы с памятью и указателями он надежнее других языков. В итоге мы чаще сталкиваемся не с чисто «программистскими» ошибками, а с логическими.
3. Сборка исходного кода
Паранойя может быть полезна! Мы стараемся устранять вообще все ошибки, о которых сообщает компилятор – даже если это всего лишь предупреждение или информационное сообщение.
Кроме того, важно отслеживать, из какой версии исходного кода была собрана программа, поскольку компилировать код приходится часто. Поэтому мы придерживаемся принципов CI/CD и используем серверы сборки. Если обнаружится баг, можно легко определить, где в исходном коде его искать и какая версия ушла заказчику для тестирования.
4. Больше Code Review!
Когда разработчик заканчивает какую-то задачу, его работа сливается с общей веткой. Написанный им код используют другие члены команда на следующих этапах. И если это решение не оптимально или приводит к запутанности кода, команде придется несладко. Поэтому сперва такой код просматривает технический руководитель проекта. Так мы не допускаем накопления ошибок.
5. Внутренняя документация
Да, никто не любит бумажную волокиту. Но когда целая команда работает над сложным проектом, без канцелярщины не обойтись. Во внутренней документации отображаются основные технические особенности проекта, требования к продукту, всевозможные неочевидные детали. Также опыт научил нас составлять тестовую документацию параллельно с разработкой, не дожидаясь завершения этого этапа. Наконец, всю документацию проверяет тестировщик – прежде всего, на полноту требований с точки зрения проверки результатов.
6. Документация для заказчика
Разработанный продукт заказчик будет продавать или интегрировать в свою систему. А значит, мы должны предоставить инструкцию по сборке, информацию по сервисным операциям и другие документы. Если после передачи продукта клиент способен решить все проблемы самостоятельно, то продукт получился качественным.
Как мы обеспечиваем качество аппаратного обеспечения
1. Собираем требования
Помним, что качество разработки определяется соответствием результата заявленным требованиям. Однако заказчик может не упомянуть что-то, что ему покажется незначительным или очевидным. Что делать? Задавать как можно больше вопросов! Чем больше деталей выжмем, тем лучше.
2. Выбираем компонентную базу
В хорошем устройстве компоненты должны быть качественные и подходящие по характеристикам. Так, между двумя транзисторами с рассеиваемой мощностью 4 и 0,5 Вт мы выберем второй, т.к. он меньше греется. Разумеется, если позволяет бюджет. Мы также отдаем предпочтение компонентам, качество которых уже подтверждено теми или иными сертификатами.
3. Тщательно изучаем документацию к компонентам
Это особенно важно, когда работаешь с компонентом впервые. Если позволяют бюджет и время или если это ключевой элемент устройства, мы также тестируем его. Дело в том, что производители компонентов не горят желанием рассказывать о недостатках своих продуктов.
Так, в одном проекте нам нужен был LTE-модуль со встроенной функцией спутникового геопозиционирования. В документации выбранного нами компонента было написано, что что он может выполнять обе функции. Но на испытаниях выяснилось, что использовать их одновременно нельзя.
4. Применяем знания и опыт
Речь о том, чтобы при проектировании платы учитывать банальные законы физики. Например, если по дорожке предполагается пустить большой ток, она должна быть достаточно большой, чтобы не выгорела.
5. Учитываем требования производства
Мало просто сделать кастомное устройство, которое работает так, как хочет заказчик. Плата должна легко изготавливаться стандартными производственными процессами, а компоненты должны быть доступны. То есть дизайн должен учитывать возможность массового производства.
6. Не забываем про условия эксплуатации
Устройство должно не только работать правильно, но и выживать в тех условиях, в которых его предполагается эксплуатировать. Для защиты от перегрева, греющиеся элементы размещаются под радиатором или ближе к вентиляционным отверстиям. Часто требуется защита от электромагнитных помех. Влажная среда? Заливаем плату компаундом или покрываем лаком. Качественные решения часто имеют избыточную защиту. Например, на устройства с батарейным питанием ставится защита от переполюсовки.
7. Делаем прототипы
Когда заказчик просит создать что-то необычное, лучше начать с разработки прототипа. Он делается «на коленке», а потому дешев и требует меньше трудозатрат, чем полноценное устройство. На нем можно проверить то или иное решение на работоспособность, найти оптимальный вариант и лишь после этого вкладывать силы и деньги в полноценный продукт.
Важно учиться на собственных ошибках и успехах
По окончании работы важно зафиксировать удачный и неудачный опыт. Это, конечно, не исправит выполненный проект, но поможет при работе над следующим. Так формируются внутренние стандарты работы, которые также определяют качество наших разработок.
После каждого проекта команда собирается, чтобы подвести итоги, обсудить удачи и неудачи, понять, из-за чего возникли сложности. Выводы фиксируются в базе знаний компании в качестве рекомендаций по выбору инструментов, порядку выполнения задач и т.п.
Важно также фиксировать опыт работы с теми или иными компонентами. В одном проекте мы поставили на плату китайский микроконтроллер, у которого память состояла из двух чипов и была фактически разделена на быструю и медленную. В одной части прошивка летала, а в другой – тормозила. В документации к микроконтроллеру это не указали. Но мы тебя запомнили, товарищ!
Много внимания уделяется различным аспектам разработки как до, так и во время и после самого процесса. Именно такой системный подход позволяет добиться высокого качества результата.