Sdlc что это такое простыми словами
(S)SDLC, или Как сделать разработку безопаснее. Часть 1
С каждым годом культура разработки растет, появляются новые инструменты для обеспечения качества кода и новые идеи, как эти инструменты использовать. Мы уже писали про устройство статического анализа, про то, на какие аспекты анализаторов нужно обращать внимание, и, наконец, про то, как с организационной точки зрения можно построить процесс на основе статического анализа.
Отталкиваясь от вопросов, с которыми мы часто сталкиваемся, мы описали весь процесс внедрения сканера кода в процесс безопасной разработки. Сегодня речь пойдет о том, как выбрать подходящий вам анализатор.
Все разработчики так или иначе сталкиваются со статическим анализом (анализом кода без выполнения). Например, когда компилятор по результатам сборки выдает какие-то ошибки или предупреждения — это результаты статического анализа. Мы часто используем линтеры — это тоже статический анализ, хоть зачастую и очень простой. Есть и более интересные примеры — spotbugs (ранее — findbugs), который позволяет находить довольно интересные уязвимости в байткоде Java, или хорошо известный SonarQube — платформа для контроля качества кода.
Однако с полноценными SAST-инструментами пока мы сталкиваемся редко. В первую очередь мы говорим про тулы, которые могут находить сложные уязвимости. Как оказывается на практике, открытые известные инструменты не справляются с этой задачей, как минимум потому, что фокусируются на другой области (баги и простые уязвимости). Хороший SAST-тул реализует межпроцедурный анализ потока данных. Анализ должен проходить не на тексте программы, а на внутреннем представлении — CFG, AST и т.п. Про это подробнее лучше почитать в предыдущей статье.
Здесь приведем пример — всем известную SQL-инъекцию. В этом примере данные от пользователя попадают в функцию completed из запроса, передаются в функцию injectableQuery и уже там попадают в SQL-запрос, делая приложение уязвимым к SQL-инъекции.
Для того чтобы найти такую уязвимость, нужно понимать, откуда могут приходить “плохие” данные, как такие данные могут валидироваться, где их нельзя использовать. И самое важное — нужно отслеживать передачу данных по всему приложению, это и есть dataflow-анализ. Пример очень простой, в реальном же приложении данные могут пройти через множество функций и модулей, присваиваний и синонимов.
Понятно, что текстовый поиск не найдет такую уязвимость. Внутрипроцедурный анализ также не найдет, а в некоторых открытых инструментах только он и реализован. Чтобы находить такие уязвимости (а это обычно и есть самые критические уязвимости, то есть главная цель работы SAST-тула), нужны хорошо проработанные алгоритмы межпроцедурного анализа потока данных с большими базами правил.
Именно исходя из алгоритмической сложности возникает ряд технических вопросов, которые отличают внедрение SAST-инструмента от других статических анализаторов, например, SonarQube. Эти вопросы мы и обсудим в серии статей. Спойлер: потребление ресурсов, продолжительность анализа, ложные срабатывания.
Надо упомянуть, что помимо алгоритмов хороший инструмент оборачивает всю математику в удобную интерфейсную оболочку, позволяя использовать SAST без серьезной подготовки. Такие инструменты также встраиваются в CI/CD с помощью плагинов и API, таким образом автоматизируя поиск уязвимостей и позволяя строить процессы безопасной разработки.
В первой статье мы попытались классифицировать основные вопросы, которые возникают при изучении SAST, а также и после решения внедрить инструмент. О каких-то вопросах поговорим здесь, какие-то уйдут в следующие статьи.
Начнём
Зачем SAST, если уже есть бесплатные статические анализаторы?
Этот вопрос мы частично затронули в предыдущей части. Мы, конечно, ни в коем случае не умаляем заслуги открытых инструментов. Все знают SonarQube — прекрасный инструмент для автоматизации оценки качества кода, с большим количество поддерживаемых языков, интеграций и плагинов. SonarQube хорош для встраивания в процесс разработки, но предназначен больше для подсчета различных метрик кода и поиска достаточно простых ошибок или уязвимостей. В нем не реализован межпроцедурный анализ потока данных, соответственно, его нельзя использовать для поиска сложных уязвимостей. Обычно мы рекомендуем использовать как SonarQube, так и хороший SAST-тул (тут может быть полезно, если SAST-тул умеет интегрироваться с SonarQube).
Есть и другие хорошие открытые статические анализаторы. Можно назвать spotbugs (findbugs) для байткода JVM с плагином find-sec-bugs, в котором реализован внутрипроцедурный анализ потока данных с небольшим набором правил. Для Python есть известный анализатор bandit. Нельзя не упомянуть встроенный в clang статический анализатор, который обладает и хорошим движком анализа, и неплохой базой правил.
Проблемы таких инструментов в том, что обычно они довольно узко специализированы (например, подходят для одного языка), реализуют простые алгоритмы (то есть не позволяют находить сложные уязвимости), обладают сильно меньшими базами правил, чем коммерческие инструменты. Помимо этого они обладают меньшим набором функциональности, как интерфейсной, так и интеграционной. Ну и можно упомянуть отсутствие поддержки.
С другой стороны хорошие коммерческие SAST-тулы (а есть и нехорошие) реализуют сложные специфические алгоритмы и обладают обширными базами правил, которые могут насчитывать тысячи записей. Обычно они поддерживают много языков программирования, обладают богатыми возможностями интерфейса и интеграции (плагины, API). Ниже привожу пример, о каких интеграциях может идти речь.
А еще ниже посмотрите на пример схемы интеграции, которую можно построить на основе SAST-инструмента. В целом схема не отличается от внедрения других средств контроля качества кода. Разработчики пишут код и могут сразу запускать проверку SAST. Код попадает в репозиторий и оттуда по различным триггерам с помощью CI/CD попадает в SAST. Результаты сканирования можно либо смотреть в интерфейсе SAST, либо они могут попадать в средства, обеспечивающие процесс разработки (багтрекер, почту и т.п.).
Какой SAST-тул выбрать?
Немного остановлюсь на этапе выбора инструмента. SAST-тулов довольно много, на рынке обычно представлено несколько штук (3-4). Возникает вопрос, как выбрать нужный инструмент, на что обращать внимание? Тут не буду удивлять, остановлюсь на трех пунктах: функциональное сравнение, сравнение по качеству и лицензирование. Важно взять инструмент на тестирование (пилот) в свой локальный контур и проверять на своем коде в своей инфраструктуре.
Хорошо бы попробовать все фичи интерфейса, понять, насколько они применимы к вашему кейсу и насколько ими удобно пользоваться. Отсылаю к одной из предыдущих статей. Приведу несколько полезных фич:
Для проверки качества нужно просканировать ваш код. Хорошо выбрать несколько разных примеров на разных языках, чтобы выборка была репрезентативна. С точки зрения качества нужно смотреть на ложные срабатывания (там, где явно нет уязвимости, а тул показывает) и на пропуски (в идеале нужно знать, где есть уязвимости, ну или сравнивать найденные уязвимости в разных тулах). Я бы чуть меньше внимания обращал на ложные срабатывания, так как обычно достаточно один раз пройтись по результатам сканирования, пометить ложные, и дальше они не будут беспокоить вас.
Остановлюсь на двух важных моментах. Во-первых, очень важно смотреть на все это в применении именно к вашей ситуации. Проверять именно ваш код (SAST может по-разному работать на разных типах приложений). Искать те фичи, которые нужны вам для встраивания тула в процесс разработки. Проверять интеграции с системами, которые у вас есть.
Во-вторых, очень важно во время пилота общаться с вендором. SAST — не самая простая штука, и часто достаточно получить обычную консультацию от вендора, чтобы оценить в полную силу мощь инструмента.
В какой момент запускать сканирования?
При таком подходе мы еще и получаем бонус: разработчики, когда видят результаты SAST “каждый день”, продвигаются в знаниях безопасного программирования, таким образом в целом повышается культура безопасной разработки и код становится лучше.
Само собой, при внедрении SAST в процесс разработки необходимо внедрение в CI/CD, построение DevSecOps. Тренд переноса SAST с контрольных проверок перед релизом в процесс разработки виден давно, и в последние 2-3 года он догнал наш рынок. Сейчас ни один пилот не проходит без тестирований возможностей интеграции.
При этом я бы оставлял контрольные проверки перед релизом, в идеале, — по бинарным сборкам (такое тоже возможно). Так можно удостовериться, что никаких новых уязвимостей не было добавлено в процессе сборки и переноса приложения в продуктив.
Технические вопросы
А дальше приведу сразу 4 вопроса.
Организационные вопросы
Я бы не стал забывать и про организационные вопросы. В больших компаниях их возникает немало, от самого процесса внедрения, выделения ресурсов до создания регламентов и тиражирования процессов.
Организационные вопросы порождаются теми же техническими особенностями, которые мы обсуждали в предыдущем пункте. Ну а помимо этого пока никуда не девается исторически сложившееся разделение и противостояние разработки и безопасности. Также отсылаю к предыдущей нашей статье.
Жизненный Цикл Разработки ПО (SDLC)
Жизненный цикл разработки ПО (System/Software Development Life Cycle, SDLC) — процесс, состоящий из конкретных этапов, который начинается в момент принятия решения о необходимости создания ПО и заканчивается в момент прекращения поддержки ПО разработчиками.
Применение SDLC позволяет:
В статье рассмотрим основные этапы жизненного цикла разработки ПО (SDLC) и их предназначение.
Этапы жизненного цикла разработки ПО
Всего выделяют 7 основных этапов разработки [1]:
Этап закрытия представлен на изображении, но он не является обязательным и зависит от проекта.
Этап 1: Идея
Разработка любой системы или ПО начинается с генерации идей для решения какой-то конкретной проблемы пользователя.
Этот процесс может быть формальным (например, brainstorming в компании) или не формальным (например, за барной стойкой с друзьями).
После генерации идей они анализируются, оцениваются и выбирается одна, которую будут «прорабатывать».
Этап 2: Определение требований
На этом этапе “идея” принимает более осмысленный и конкретный вид.
Для определения начальных требований к продукту привлекаются эксперты из разных областей: заказчики, клиенты, специалисты разных отделов (продаж, разработки, аналитики, тестирования и т.п.), эксперты по схожим продуктам.
Бизнес-аналитики (BA) прорабатывают полученную информацию, детализируют ее и преобразовывают в технические требования к системе. Эти требования называются Software Requirement Specification (SRS).
Кроме SRS на этом этапе:
Этап 3: Дизайн (архитектура) системы
На этапе дизайна системы архитекторы ПО создают “скелет” проекта основываясь на требованиях. Они определяют используемые технологии, инструменты, рабочие процессы, взаимосвязи между разными частями проекта, структуры баз данных, потоки данных и т.п.
В итоге определяется спецификация по дизайну (Design Document Specification, DDS) с описанием что и как нужно делать с технической точки зрения.
DDS может состоять их двух частей — высокоуровневый дизайн (High-Level Design, HLD) и низкоуровневый дизайн (Low-Level Design, LLD).
Этап 4: Разработка
Разработчики получают требования (SRS), спецификацию по дизайну (DDS) и создают требуемое ПО.
Качество требований напрямую влияет на стоимость и продолжительность разработки. Чем хуже требования, тем больше ошибок нужно будет исправить, следовательно, увеличиваются незапланированные расходы.
Этап 5: Тестирование
Тестировщики, основываясь на требованиях (SQA, SRS, DDS) и готовом продукте производят проверку качества ПО (Quality Control).
Если находятся отклонения от требований / ошибки — они оформляются в виде отчетов о дефектах, исправляются и перепроверяются.
Процесс продолжается до тех пор, пока качество продукта не будет доведено до приемлемого уровня.
Этап 6: Развертывание
После успешного тестирования готовый продукт передается заказчику.
Кроме передачи может производится настройка рабочих окружений, установка, конфигурация и запуск продукта.
Этап 7: Поддержка
После запуска продукта он начинает развиваться, изменяться, дополняться новыми функциями.
Эта часть жизненного цикла является самым длительным и важным этапом разработки ПО.
Без наличия процессов и стандартов разработки, рабочих процедур, порядка в документации, налаженной коммуникации и регрессионных тестов разработка очень быстро превращается в кошмар с микро-менеджментом, постоянно не закрывающимися задачами, кучей багов, огромным техническим долгом, развалом команды или проекта.
Именно на этом этапе умирает большинство стартапов.
Дополнительный этап: Закрытие
Закрытие — последний этап жизни ПО. На нем происходит вывод продукта из эксплуатации, его замена на современные аналоги, либо новые версии.
Как пример, можно вспомнить браузер Internet Explorer (был замен на Edge) или Windows XP (заменена на Windows 7).
Длительность разработки ПО
Для простых проектов разработка длится несколько месяцев (например, не “взлетевшие” стартапы, небольшие сайты, и т.п.).
Для сложных — более 15 лет (например, ПО для космических аппаратов).
Но, для большинства проектов, активная разработка продолжается на протяжении 6-8 лет. [2]
Учитывайте это, когда устраиваетесь на работу 🙂
Резюме
В статье мы разобрались, что такое жизненный цикл разработки ПО (SDLC), рассмотрели его этапы и их особенности.
Мы поняли, что создание программного обеспечения — это не только написание кода. В этот процесс входит много подготовительной (анализ, создание требований) и дополнительной работы (тестирования, разворачивание), а самым важным этапом является поддержка.
Далее, можем рассмотреть методологии разработки ПО которые реализуют этапы жизненного цикла ПО.
Что такое SDLC?
Жизненный цикл разработки ПО (System/Software Development Life Cycle, SDLC) — процесс, состоящий из конкретных этапов, который начинается в момент принятия решения о необходимости создания программного продукта и заканчивается в момент прекращения поддержки ПО разработчиками.
Какие основные этапы SDLC?
Основными этапами SDLC являются:
1. Идея
2. Определение требований
3. Дизайн (архитектура) системы
4. Разработка
5. Тестирование
6. Развертывание
7. Поддержка (самый важный этап)
Что такое SDLC (жизненный цикл разработки программного обеспечения)?
Как разработчики обеспечивают соответствие своих приложений всем спецификациям? Когда они тестируют свой код? Каковы подходящие временные рамки для анализа требований?
Без ответов на эти вопросы разработчики программного обеспечения были бы в растерянности, когда бы они ни работали над новым проектом. Как они узнают, что делать и когда? Вот где вступает в игру жизненный цикл разработки программного обеспечения (SDLC).
В этом руководстве мы собираемся обсудить основы SDLC. Мы поговорим о каждой фазе SDLC и предоставим вам примеры того, как жизненный цикл используется на практике.
Что такое SDLC?
Жизненный цикл разработки программного обеспечения — это методология, которая описывает, как вам следует подходить к разработке программного обеспечения. Этот процесс гарантирует, что вы создаёте программное обеспечение в правильном порядке, и помогает сделать разработку более эффективной.
Жизненный цикл разработки программного обеспечения важен при разработке проекта, потому что он позволяет каждому в команде проекта — от менеджеров до разработчиков — отслеживать проект. Членам команды нужно только понимать основы жизненного цикла, чтобы получить точное представление о ходе проекта и о том, когда его части или все будут завершены.
Жизненный цикл разработки программного обеспечения полезен, потому что он чётко определяет, какие действия происходят на определённых этапах процесса разработки. Если вы новичок в программировании, очень полезно иметь чёткое представление о том, что вам нужно делать и когда, а также какие результаты должны быть получены и когда.
Жизненный цикл разработки программного обеспечения обычно контролируется менеджером проекта, который обеспечивает достижение разработчиками своих целей.
Как работает SDLC?
Жизненный цикл разработки программного обеспечения состоит из семи этапов, описывающих, как следует разрабатывать программный проект. Хотя у каждого есть своё имя для каждой стадии SDLC, вот основные темы, которые вы увидите на протяжении жизненного цикла:
Давайте углубимся в каждый из этих этапов и обсудим, как они работают и как они применяются при разработке программного проекта.
Этап 1: Анализ и планирование
Прежде чем вы сможете разработать проект или создать для него функцию, вам сначала нужно знать, что вы собираетесь построить. Какие особенности должен иметь проект? Каких функций у него не должно быть?
Хотя многие люди рассматривают разработку программного обеспечения как простое кодирование, на самом деле это гораздо больше, чем просто ввод кода. Вам нужно будет определить объём и границы проекта, прежде чем вы начнёте писать код. Здесь вы поймёте, что вы собираетесь построить и почему.
На этапе анализа и планирования вы будете работать со всеми заинтересованными сторонами проекта — от руководителей до других разработчиков и клиентов — чтобы обеспечить разработку соответствующих спецификаций проекта. Вам необходимо убедиться, что проект соответствует не только ожиданиям клиентов, но и целям вашего собственного бизнеса.
Этап 2: Дизайн
Итак, у вас есть план того, что вы хотите построить. Теперь вы должны спросить себя: как мы выполним этот план? Как мы собираемся создавать выявленные нами особенности?
Следующим этапом SDLC является этап проектирования. Именно здесь вы будете решать, как должны быть реализованы функции. Работая со всеми заинтересованными сторонами, чтобы ваши планы соответствовали их потребностям.
Работа с другими важна на каждом этапе SDLC, но особенно на этапе проектирования. Вы можете понять, что вам нужно создать, но, если вы не получите мнение всех заинтересованных сторон, ваш дизайн может не соответствовать всем требованиям.
Этап 3: Разработка
После планирования и проектирования вы готовы приступить к разработке. Здесь вы откроете терминал и текстовый редактор, чтобы начать работу над проектом. Вы потратите много времени на создание всех функций, согласованных в ходе предыдущих обсуждений.
Разработка — это не только написание кода. На этом этапе вам необходимо встретиться с другими разработчиками, чтобы распределить работу и обсудить, кто лучше всего подходит для решения конкретных проблем. Скорее всего, вы разработаете процесс, который поможет вам эффективно писать код в команде.
Этап 4: Тестирование
Вы сделали тяжёлую работу, и функции, необходимые для создания, готовы, но вы ещё не закончили. Что делать, если ваш код содержит ошибки? Или что, если ваш проект не работает в данном пограничном случае?
Здесь вступает в игру фаза тестирования. Вам нужно будет определить, какие проблемы существуют в вашем коде, и создать решения этих проблем, чтобы конечный продукт соответствовал спецификациям, изложенным на этапе анализа.
Этап 5: Развёртывание
Готовый продукт готов. Вы протестировали код и убедились, что конечный продукт соответствует всем исходным спецификациям. Теперь вы готовы начать развёртывание проекта.
Здесь вы перенесёте разработанное вами программное обеспечение из среды тестирования в рабочую среду. Например, с помощью веб-приложения вы можете переместить свой код на работающий веб-сервер, на котором размещён ваш веб-сайт; с игрой вы можете опубликовать свой код в игровом магазине.
Этап 6: Обслуживание и оценка
Хотя планирование является важной частью SDLC, вы обнаружите, что потребности проекта со временем изменятся. Возможно, пользователи просят добавить другую функцию или обновить библиотеки, чтобы продукт по-прежнему работал с использованием новейших инструментов.
После публикации проекта вы будете отвечать за его поддержку. Часто разработчики используют инструменты мониторинга производительности приложений, чтобы убедиться, что их код работает эффективно. Если разработчики не поддерживают свои приложения, они могут стать нестабильными и перестать соответствовать исходным требованиям проекта. Это вредно для деловых отношений.
Как применяется SDLC
Жизненный цикл разработки программного обеспечения может быть применён к программному проекту несколькими способами. Вы обнаружите, что нет двух одинаковых команд разработчиков. Каждый будет использовать свои собственные модели для реализации SDLC, сохраняя при этом лучшие практики, которые управляют этой моделью.
Давайте обсудим три из самых популярных моделей SDLC, используемых командами разработчиков программного обеспечения.
Модель водопада
Модель водопада, пожалуй, самая распространённая реализация SDLC. С помощью этой модели вы переходите к следующему этапу цикла после завершения текущего этапа. Например, вы начнёте с анализа, а после его завершения перейдёте к этапу проектирования.
Эта модель полезна тем, что легко оценить прогресс. Однако у него есть и недостатки. Например, если вам нужно вернуться назад, потому что требования к программному обеспечению изменились, ваш конечный продукт может не соответствовать всем целям, если у вас нет систем для возврата и исправления кода, который может больше не иметь значения.
Гибкая модель
В гибкой модели используется циклический подход к разработке программного обеспечения. Это означает, что работа выполняется циклами, известными как спринты, которые обычно длятся от двух недель до месяца.
Agile поддерживает итеративную разработку. Это означает, что, если вы поймёте, что продукт не соответствует своим начальным спецификациям. Вы можете легко вернуться к этапу проектирования и внести необходимые изменения. Эти изменения будут внесены в следующем спринте.
Инкрементальная модель технически является частью модели водопада. Это серия водопадных циклов. В этой модели разработчики объединяются в группы и разделяют требования к проекту. Затем каждая группа реализует согласованный SDLC.
Это хорошая модель для использования, когда вы работаете над большим проектом с множеством требований, поскольку она может помочь вам разбить то, что необходимо для продвижения общего развития проекта.
Существуют и другие модели, такие как модель большого взрыва, спиральная модель и v-модель. Однако три модели, которые мы только что обсудили, являются наиболее распространёнными.
Заключение
Команды профессиональных разработчиков используют жизненный цикл разработки программного обеспечения, чтобы гарантировать, что участники не упустят из виду задачи, которые необходимо выполнить, например, тесты, которые необходимо запустить, или функции, которые необходимо создать. Жизненный цикл создаёт стандартный подход к разработке программного обеспечения. Поэтому каждый разработчик знает, что от него ожидается и когда. Всё это гарантирует, что проекты будут доставлены клиентам вовремя и в соответствии с ожиданиями.
Что такое Жизненный Цикл Разработки ПО и какие проблемы возникают на каждом этапе SDLC?
Жизненный цикл разработки ПО (англ. SDLC – Software development lifecycle) – это серия из шести фаз, через которые проходит любая программная система.
Абсолютно любое ПО проходит через 6 основных шагов, начиная от простой идеи и заканчивая использованием её конечным пользователем.
Но как это выглядит изнутри? С какими сложностями сталкивается команда разработчиков и как их решает на каждой фазе Жизненного Цикла ПО? Об этом расскажет Павел Гапонов, Project Manager компании-разработчика SolveIt.
Типичный жизненный цикл разработки состоит из следующих фаз:
Это, пожалуй самый ответственный и важный из всех шагов к созданию успешной программной системы. Вся собранная информация используется для планирования базового проектного подхода.
Дополнительно идет планирование требований по обеспечению качества и выявления различных рисков, связанных с проектом. Результатом анализа является определение различных технических подходов, которые можно использовать для успешной реализации проекта с минимальными рисками. Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода ко второму этапу.
Проблема: Не соответствующие ожидания и часто изменяющиеся требования: заказчик и команда не понимают, какую реально пользу принесёт продукт.
Решение: Определить скоп работ, согласовать четкий, краткий документ с требованиями, создать прототипы (макеты) для подтверждения и уточнения окончательных требований.
Как только базовый анализ требований будет выполнен, следующим шагом будет четкое определение и документирование требований к продукту, утверждение со стороны клиента. Если одной из целей первого этапа является понимание и анализ требований, то на этом этапе все цели должны быть прописаны, это защита обеих сторон.
Важно четко определить и прописать, что требуется выполнить, это делается с помощью SRS (Software Requirement Specification). Документ содержит все требования к продукту, которые должны быть спроектированы и разработаны в течение жизненного цикла проекта.
Проблема: Большой многостраничный список требований
Решение: Выяснить высокоуровневые требования и, в ходе разработки и коммуникации с заказчиком, дописывать ТЗ. То есть разработка идет параллельно с Техническим заданием, а в процессе корректируется план.
В SolveIt мы всегда стараемся быть гибкими и подстраиваться под клиента. Работающий продукт важнее исчерпывающей документации.
SRS это ориентир для разработчиков, чтобы предложить лучшую архитектуру для продукта. Обычно предлагается несколько подходов к проектированию архитектуры продукта. Все предложенные подходы документируются в спецификации DDS (Design Document Specification) и выбирается наилучший подход к проектированию. Данный подход очень четко определяет все архитектурные модули продукта, а также его связь с внешними и сторонними модулями.
Проблема: Выбрали неправильную архитектуру.
Решение: Наличие в команде разработчиков опытных лидов, которые смогли бы предложить подходящую архитектуру, на основе своего успешного опыта в схожих проектах.
Здесь начинается разработка и сборка продукта. Весь программный код, новые модули и фичи разрабатываются на основании DDS. Чем лучше написана эта документация, тем быстрее будет идти имплементация. На этом этапе подключается команда разработчиков. Написанный код должен покрываться Unit-тестами, а взаимодействие новых фич с другими модулями тестироваться с помощью интеграционных тестов. Эти активности выполняются именно командой разработчиков, а не QA специалистами.
Проблема №1: Слабая коммуникация между командой
Разработчик не интересуется прогрессом проекта, проблемами коллег.
Решение: Daily meetings, 100% вовлеченность, Скрам доска (интерактивность).
Проблема №2: Невыполнимые сроки
Заказчик хочет, чтобы его продукт был готов в ближайшее время. Менеджер проекта пытается объяснить клиенту к чему приведет такая спешка, но этого не достаточно. Клиент ставит невыполнимые дедлайны и не слушает возражения менеджера проекта. В результате, команда разработчиков сдается и пробует закрыть задачи в слишком короткие сроки. Как следствие – критические баги из-за спешки: команда не успевает, качество продукта снижается, клиент не доволен и решает, что виновата команда.
Решение: Менеджер проекта должен стоять на своём и аргументировать дедлайны. Клиент должен понять, что если команда разработчиков будет торопиться, то не реализует часть функционала. Если всё же такой срок реализации критичен для клиента, мы стараемся выявить какие задачи находятся у заказчика в приоритете.
Проблема №3: Добавление не оговоренных фич
Решение: Менеджер проекта должен объяснить клиенту, к чему приведет добавление новых фич в проект, отстаивать свою позицию и держаться SRS. Поэтому так важна вторая фаза Жизненного цикла разработки ПО.
Именно тестирование, в основном, затрагивает все этапы жизненного цикла. Дефекты продукта регистрируются, отслеживаются, исправляются и повторно тестируются. Это происходит до тех пор, пока продукт не достигнет стандартов качества, которые прописаны в SRS. На данном этапе в процесс разработки подключается команда мануальных тестировщиков или автоматизаторы.
Проблема: Тратится слишком много времени на поиск причин багов. Попытки найти и исправить дефекты после завершения разработки – сложный процесс, который может привести к большому количеству исправлений.
Решение: Проводить тестирование параллельно задачам, сразу же по их завершению.
Как только продукт протестирован, он выходит в релиз. Иногда внедрение происходит поэтапно, в соответствии с бизнес-стратегией. Продукт сначала может быть выпущен в ограниченном сегменте и протестирован в реальной бизнес-среде, это UAT-тестирование (User Acceptance Testing). Затем, основываясь на отзывах, продукт может быть выпущен как есть, или с предлагаемыми улучшениями. После того, как продукт выпущен на рынок его обслуживание выполняется для существующей клиентской базы, и на этом этапе подключаются Support-команды.
Проблема №1: Отсутствие обратной связи, реальных отзывов потенциальных пользователей продукта.
Решение: Не ждать конца разработки, а как можно скорее запускать продукт, чтобы получить отзывы от реальных пользователей и на основе их предпочтений приоритезировать дальнейший функционал.
Проблема №2: Слабая инфраструктура проекта на стороне клиента.
Часть заказчиков предпочитают размещать сервера приложений не на Azure, AWS, Google и т.д, а в своей внутренней сети. Команда не может гарантировать стабильную работу, из-за сбоев, которые происходят на стороне клиента.
Решение: Предупредить клиента, о возможных проблемах, предложить решения для их устранения.
Если вам нужен качественный продукт, свяжитесь с нами и мы сделаем оценку вашего проекта!