Роман Еникеев в прямом эфире Митапа в ОЭЗ "Иннополис" рассказал о том, что нужно понимать под защищенностью данных, немного об изменении мира к лучшему, путем создания хорошего программного продукта и его характеристиках. Вы узнаете о пирамиде нахождения багов и о самой поддержке продукта.
Роман имеет более 12 лет опыта в IT, занимается full-stack разработкой, на данный момент, большую часть времени занимается delivery manager. Спикер более 10 лет работает в компании DataArt.
Когда речь идет о разработке программного продукта, важно определить метрики оценки качества. Для этого может быть использовано множество разных метрик, но все же всю суть этого процесса изложено в высказывании Тома де Марко: “Качество программного продукта является показателем того, насколько он меняет мир к лучшему”. Качество продукта - это, в первую очередь, польза, которую несет продукт пользователям. Согласно формальным документам, характеристиками верхнего уровня являются:
функциональная пригодность
уровень производительности
совместимость
удобство использования (юзабилити)
надежность
защищенность
сопровождаемость
переносимость (мобильность)
Тем не менее, если продукт работает с данными, например, медицинскими, специально разрабатываются системы контроля качества кода. Создаются специальные процессы, которые помогают минимизировать риски утечки конфиденциальных данных. Таким образом становится понятно, как будут вноситься изменения при обнаружении каких-либо недостатков системы.
У каждой системы разный уровень строгости. Например, в случае разработки аппарата компьютерной томографии, мельчайшая ошибка может стать причиной смерти пациента. Именно поэтому Quality Management System для медицинских устройств обладает максимальной строгостью. Да и в целом, сфера медицинской разработки находится в топ 5 сфер по строгости.
В случае разработки программного обеспечения, которое будет хранить данные банковских карт, важным этапом является прохождение сертификации PCI DSS. Именно поэтому есть специальные чек-листы и аудиторские компании, которые анализируют все особенности и безопасность программного продукта. Критерии качества, в случае приложения хранящего банковские данные, будут отличаться от критериев качества медицинского программного обеспечения.
При разработке программного продукта важно оценивать его качество не только с бизнес стороны, но и со стороны пользы. Да, защищенность, переносимость и эффективность основываются на требованиях к продукту, но именно процесс разработки влияет на конечное качество.
Защищенность
Защищенность - это обеспечение программой безопасного хранения критичных данных. Это сопровождается постоянным тестированием во время разработки продукта. Также, для понимания возможных уязвимостей, рекомендуем ознакомиться с топ 10 уязвимостей для web-приложений по версии OWASP.
Итак, по версии OWASP самыми критичными уязвимостями считаются:
Некорректная аутентификация и управление сессией
Утечка чувствительных данных
Нарушение контроля доступа
Межсайтовый скриптинг
Отсутствие документирования и мониторинга
Мы считаем, что каждый разработчик должен знать о критических уязвимостях, чтобы уже на начале разработки проекта их избежать. Кстати, OWASP предоставляет аудиторские гайды по тестированию систем. Например, одним из самых популярных гайдов по аудиту является гайд для WordPress. Используя его, вы сможете разработать надежный сайт, который будет трудно взломать, чтобы получить критическую информацию.
Тестирование
Разработка системы не может вестись без ошибок. Есть очень мало разработчиков, которые могут писать код идеально. Чтобы искать баги и вовремя их исправлять, мы рекомендуем использовать принцип пирамиды, представленный ниже.
Как показывает практика, лучше всего отслеживание багов происходит с помощью автоматического тестирования. После сборки продукта его необходимо протестировать, развернуть инфраструктуру и еще раз проверить на наличие багов в коде.
По большому счету, если смотреть на следующую пирамиду, то у нас есть разные уровни. Мы можем уйти от Unit Tests на Service Tests и на UI Tests. В случае Unit Tests мы знаем, что их быстро писать, они быстро прогоняются, но они тестируют в более изолированной системе. Если же мы уходим на UI, которые пишутся дольше и существенно дольше выполняются, они могут проконтролировать корректность работы нашей системы с большим количеством компонентов. Если система построена вокруг сервисов, то очень полезной практикой является тестирование контрактов между этими сервисами на соблюдение изменений.
При написании любого теста необходимо каждый раз задавать себе вопросы, например, упадет ли тест, если что-то пойдет не так. Важно помнить, что тесты - это тоже код, поэтому к нему нужно тоже подходить достаточно ответственно.
Модифицируемость / поддерживаемость
Существует 4 типа:
Использование корректировок (возможность исправлять ошибки, возникающие в момент пользования)
Адаптация к изменениям в окружающей среде (требования постоянно меняются, поэтому мы должны всегда совершенствовать систему)
Постоянно улучшать, а не ухудшать систему
Профилактика процессов, чтобы не бояться вносить изменения
Источник: innevia.tech