Sdlc фреймворк что это
Как разработчики обеспечивают соответствие своих приложений всем спецификациям? Когда они тестируют свой код? Каковы подходящие временные рамки для анализа требований?
В этом руководстве мы собираемся обсудить основы SDLC. Мы поговорим о каждой фазе SDLC и предоставим вам примеры того, как жизненный цикл используется на практике.
Этапы SDLC и лучшие практики и методологии
В ходе разработки перед переходом от текущего этапа к следующему необходимо выполнить каждый его шаг, для чего их следует лучше понимать. В этом отношении первые три этапа стараются дать ответы на проверочные вопросы, а последние три оптимизированы для достижения фактических результатов.
- Анализ требований отвечает на вопрос «Какие проблемы требуют решений?»
- Планирование отвечает на вопрос «Что мы хотим сделать?»
- Проектирование и дизайн отвечает на вопрос «Как мы добьемся наших целей?»
- Разработка ПО регулирует процесс создания продукта.
- Тестирование регулирует обеспечение качественной работы продукта.
- Развертывание регулирует использование финального продукта.
Давайте детальнее рассмотрим каждый этап и разберем проверочные вопросы и результаты, некоторые из которых вы можете захотеть оптимизировать под вашу конкретную ситуацию.
На этом этапе SDLC вам необходимо получить обратную связь и поддержку от соответствующих внутренних и внешних заинтересованных сторон. Вспомните мой недавний пример с разработкой приложения по учету времени: вам нужно будет широко задуматься о том, кто станут вашими потенциальными пользователями. Некоторые идеи будут включать ваших клиентов, дизайнеров, вашего начальника или других технических специалистов команды. В целом вы хотите ответить на следующий вопрос: «Какие проблемы требуют решений?» Быть внимательным и делать заметки будет очень полезно на этом этапе.
Когда полученные ответы вас удовлетворят, вы сможете перейти к следующей фазе.
На этом этапе вы ищете ответ на следующий вопрос: «Что вы хотите сделать?» Этот вопрос может вдохновить вас на понимание юнит-экономики вашего плана (затраты и выгоды), факторов снижения рисков и ожидаемых стоимостей. По аналогии с планированием отпуска, вам нужно будет разложить ваши вещи и подумать о том, что следует взять с собой.
Я много читал об истории Инстаграма, чей этап планирования занял невероятно много времени. Это совпало с бурным ростом социальных сетей, поэтому взаимодействие пользователей с продуктом во многом все еще было неизвестно. Разработчики знали, что сильный первичный опыт (съемка, редактирование и обмен фотографиями) обеспечит рост, успех и высокую конверсию, а корректное планирование упростит проектирование, поэтому планировали соответствующе и тратили на дизайн много времени. Они всегда смотрели на шаг вперед и думали о будущем социальных сетей и электронной коммерции.
Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода к третьему этапу.
К этому этапу вы уже должны знать требования вашего продукта и в целом понимать чего вы вообще хотите, и прежде чем приступить к написанию кода, этого понимания должно быть достаточно для ответа на следующий вопрос: «Как мы добьемся наших целей?» Иначе говоря, вам необходимо понять, что именно вы оптимизируете и проектировать соответствующе.
Допустим, вы хотите создать безопасное, высокопроизводительное, эффективное и выдерживающее нагрузки приложение. Какой из этих четырех принципов наиболее для вас наиболее важен? Почему? Согласны ли с этим заинтересованные стороны из первого этапа? Важно обеспечить одобрение всех участников.
После фазы дизайна вы наконец-то сможете засесть за клавиатуры, и внесение изменений в отношении времени и потраченных ресурсов будет неуклонно расти, а также буду постепенно накапливаться всевозможные малые факторы. В этой фазе для принятия окончательных решений по вопросам дизайна я рекомендую учитывать несколько основных его элементов: операционное превосходство, безопасность, надежность, эффективность производительности, и оптимизация затрат.
На этапе разработки вы стремитесь не столько отвечать на вопросы, сколько произвести результаты, или, говоря точнее, вам необходимо склоняться к действиям и создать прототип или систему, испытать которую смогут другие. На этом этапе ваша задача – заручиться доверием заинтересованных сторон через воплощение образа мышления разработчика. Для соответствия результата ожиданиям критично при начале разработки следовать первым трем этапам.
Доставайте ваш компьютер, убедитесь, что окружение способствует рабочей атмосфере, хватайте ваш горячий кофе – и приступайте к делу.
Сотрудники в футболках с надписями вида «Разрабатывать круто, тестировать не очень» были для меня привычным зрелищем, но вы должны понимать, что не получится создать финальную версию продукта, пока вы на нем собаку не съедите. По завершению этого этапа вы должны будете в состоянии обеспечить рабочее состояние продукта. Отслеживайте ошибки и неточности, выслушивайте чужие точки зрения, и глубоко погружайтесь в вопрос с целью поиска тормозящих выход финального продукта ошибок. Вам просто необходимо обеспечить прочную основу.
Возьмите ваш продукт и пользуйтесь им. Предложите заинтересованным сторонам из первого этапа пользоваться вашим продуктом в естественных условиях, начните отслеживать вовлеченность в продажи. Снова и снова прислушивайтесь к пользователям, ведь благодаря обратной связи через опросы и рекомендации вы сможете вернуться к первой фазе и начать собирать новые требования. И не забудьте отпраздновать релиз.
SSDLC и итерации
Многие из нас работают в гибких парадигмах Agile. И чаще всего речь идет о каком-то итеративном фреймворке, например, о Scrum. Как SSDLC ложится на наши итерации?
По сути, мы имеем те же фазы жизненного цикла разработки ПО, только они перемешаны или наложены друг на друга.
При итерационном подходе разработка приложения проходит несколько этапов:
проработка спринтового бэклога;
аналитика (особенно если делаем что-то комплексное);
тестирование во время разработки;
На схеме зеленым отражены мероприятия, которые можно проводить на разных этапах разработки, чтобы позаботиться о безопасности. О них мы сейчас и поговорим.
Проработка бэклога (PBR)
«Разгребайте уязвимости по аналогии с багами и техдолгом каждую итерацию, занесите это в метрики команды».
На этапе формирования бэклога, помимо обычных оценок или проработки того, что мы хотим поставить в спринт, стоит разобрать возможные уязвимости по аналогии с багами и техдолгом.
Например, в Ак Барс Цифровые Технологии завели для уязвимостей отдельный тип запросов в JIRA. Он очень похож на шаблон дефекта: есть priority, severity, описание, шаги воспроизведения и т.д.
Анализ
«Анализируйте риски при проектировании решений и при проработке функциональных и нефункциональных требований».
На этапе анализа, помимо проработки требований пользовательских историй, нужно заботиться об анализе рисков.
Что такое анализ рисков? Наверное, все слышали про модель угроз, но представление о ней у всех разное. В Ак Барс это происходит следующим образом: для приложения или куска функциональности стараются создавать модели угроз, основанные на так называемом DFD (Data Flow Diagrams):
Отрисовывается схема того, как проходят потоки данных, в частности, запросы или клиентский путь. Кружочками обозначаются компоненты системы. Когда схема нарисована, становится видно, какие участки или компоненты могут быть уязвимы. Они помечаются отдельно, после чего можно построить дерево угроз. Самое важное — придумать меры защиты, прописать их и чекнуть, чтобы взять потом в работу.
Планирование итерации
«Поднимайте приоритеты для критичных уязвимостей, “продавайте” технические задачи».
Когда мы стартуем итерацию, важно поднимать приоритеты для критичных уязвимостей. Скорее всего, вы сталкивались с такой важной штукой, как «продажа» технических задач. Иногда это становится проблемой, потому что бизнес хочет бежать вперед.
Как в Ак Барс Цифровые Технологии «продают» уязвимости?
Есть поле Priority — стандартная градация приоритета, как у большинства типов issues.
У уязвимостей, как и у дефектов, есть отдельное поле Severity (серьезность). Кроме того, у Severity должна быть своя градация (Critical, High, Medium, Low, Info). От этого Severity зависит то, как быстро нужно устранить все эти уязвимости. Например, можно заявить количество дней.
Также стоит ввести еще один параметр — Risk. По сути — это некоторый количественный параметр от Severity, его scoring:
Risk = Severity score = (Application score + Business Impact)/2
Risk зависит от Application score, который дают разные инструменты для безопасности:
Application score = InCode Severity score или Nessus Severity score или SonarQube Severity score
Кроме того, в компании учитывается Business Impact, то есть влияние на бизнес, когда уязвимости могут повлечь за собой какие-то финансовые угрозы, репутационные риски либо что-то, связанное с privacy клиентов. Все это усредняется и получается некая цифра:
Business Impact = (Financial Damage + Reputation Damage + Non-Compliance + Privacy Violation)/4
Эту цифру можно показать Product Owner. Увидев высокий показатель Business Impact, он поймёт, что стоит взять эту задачу в работу и повысить ее приоритет.
Разработка
«Следите за всеми временными решениями в приложении, смотрите на все типы угроз по тому же OWASP».
Есть такая аббревиатура — OWASP — Open Web Application Security Project.
Это открытый проект обеспечения безопасности веб-приложений. Он описывает разные уязвимости и способы борьбы с ними. А кроме того, предоставляет некоторые open source инструменты.
OWASP определяет Top Ten угроз:
(A2) Broken Authentication;
(A3) Sensitive Data Exposure;
(A4) XML External Entities (XXE);
(A5) Broken Access Control;
(A6) Security Misconfiguration;
(A7) Cross-Site Scripting (XSS);
(A8) Insecure Deserialization;
(A9) Using Components w/ Known Vulnerabilities;
(A10) Insufficient Logging & Monitoring.
Не будем останавливаться на всех десяти пунктах. Но о некоторых все же стоит рассказать подробнее.
Что поможет предотвратить угрозы:
(A1) Инъекции.
Объектно-реляционное преобразование (ORM). Чаще всего в них уже вшиты определенные вещи, связанные с обработкой данных.
Валидация пользовательского ввода.
Параметризованные запросы SQL, чтобы опять же SQL, введенный злоумышленником, не мог выполниться из формы.
(А2) Некорректная аутентификация.
Алгоритм хеширования не слабее SHA256.
Логирование неудачной аутентификации. Это нужно, во-первых, для последующего анализа, а во-вторых, чтобы понимать, что что-то пошло не так, и надо алертить нездоровую активность.
Защита от перебора пароля.
Сложность вводимого пароля.
2FA. Желательно использовать двухфакторную авторизацию там, где это не ломает пользовательский путь.
(А5) Нарушенный контроль доступа.
Механизмы контроля доступа, чтобы злоумышленник не попал туда, куда нельзя.
CORS. Это настройка веб-сервера таким образом, чтобы не было нежелательных redirect’ов на недоверенные домены. Когда вы пропишете доверенные домены, приложение будет работать только с ними. А значит, атаки типа CSRF уже навряд ли пройдут.
Инвалидация сессии (для JWT-токенов). Раз мы говорим про токены (SSO-сценарий), то нужно иметь механизм отзыва сессий в случае ЧП.
Логирование нарушенного контроля доступа. Опять же мы должны логировать, триггерить, анализировать, либо сразу алертить, если вдруг появилась нездоровая активность.
Rate limit. Некоторые сервисы с высокой нагрузкой или часто используемые в других клиентах выставляют ограничения типа «Ко мне можно стучаться не больше N раз в минуту». В этом нет ничего страшного, зато они защищены от разных DDoS-атак.
(А6) Ошибки в конфигурировании:
Удалять лишние файлы и тестовый функционал в релизе.
Отключать неиспользуемые компоненты.
Отключать неиспользуемую функциональность.
Важно, чтобы не оставалось никаких дыр. Если забыть что-то протестировать, злоумышленник может найти это при помощи сканеров.
(А7) XSS (когда злоумышленник пытается выполнить свой JavaScript в нашем приложении).
Экранирование входных данных.
Content Security Policy (CSP).
Библиотеки / фреймворки (например, Microsoft AntiXSS).
(A10) Недостаточное Избыточное логирование.
OWASP говорит о недостаточном логировании для того, чтобы мы могли иметь какие-то данные для анализа. Но логичнее все же затронуть момент избыточного логирования. Особенно если речь идет о финансовом секторе.
Токены и cookie;
ФИО, персональные данные;
Серия и номер паспорта.
Конечно же, это все нужно убирать. Чтобы и разработчики к этому не имели доступа, и злоумышленники не могли этим воспользоваться.
Code Review
«Ревьюйте код не только на соблюдения правил написания кода и архитектуры, а также на наличие потенциальных дыр».
В разработке обязательно есть код-ревью. И на этом этапе нужно не просто ревьюить правила написания кода или архитектуры, а еще и смотреть на наличие потенциальных дыр.
Например, такое не должно проходить:
Тестирование и Feature Freeze
«Встройте в проверки QA анализаторы SAST и DAST, следите за алертами по уязвимостям, атакам, логам».
Если вы используете практику Feature Freeze для того, чтобы провести регрессионное тестирование в конце и все-таки удостовериться, что все ОК, можно встроить какие-то автоматические проверки. Для этого существуют разные анализаторы. Ниже поговорим о действующих инструментах.
Проверка при сборке
Часто используются SAST-анализаторы. Например, можно применять следующий инструментарий:
SonarQube. Оценка качества кода. Имеет большое количество плагинов, среди которых dependency-check. Этот инструмент также очень распространен в разработке. Наверняка многие из вас его используют. Он отвечает за качество кода, но может работать и с уязвимостям. Есть community edition, можно использовать бесплатно.
Dependency Check. Нахождение уязвимых зависимостей — библиотек и модулей. Можно использовать бесплатно.
Trivy. Проверка контейнеров на уязвимые компоненты. Интересный инструмент (и тоже бесплатный).
Проверка при деплое
Есть такой класс инструментов, как DAST-анализаторы — Dynamic Application Security Testing — это анализ на наличие уязвимостей выполняемого приложения. По сути DAST делает тест черного ящика.
При деплое в Ак Барс Цифровые Технологии пользуются следующими инструментами:
ZAP от OWASP. Бесплатный инструмент. Расширяемый, с большим количеством проверок. Автоматизируемый и вшиваемый в CI/CD.
Burp Suite. Инструмент для ручного тестирования веб-приложений.
Nessus. Сканер уязвимостей. Инструмент платный, но есть неплохая бесплатная альтернатива OpenVAS.
WFuzz. Бесплатный инструмент для тестирования уязвимостей подачи на вход некорректных данных.
Итак, мы готовы к релизу. Важно понимать, что нужно релизить только то, что не содержит критичных дефектов и уязвимостей. Если мы их пропустим, последствия будут плачевными.
Артефакты
«Фиксируйте факт релиза, прикладывайте результаты проверки – у нас заявка с артефактами на безопасников».
Хорошая идея — оставлять артефакты при релизе. Делать это при проверке как на дефекты, так и на уязвимости — крутая практика, потому что если что-то случилось, это потом можно проанализировать.
В Ак Барс используют классный бесплатный инструмент DefectDojo, который агрегирует в себе все уязвимости из большого числа инструментов. Кроме того, он умеет генерировать отчет, посмотрев который можно понять, все ли ОК.
Релиз
«Релизьте только при отсутствии критичных дефектов и уязвимостей – дефекты S1/S2 с P1 являются блокерами для деплоя».
Главное — релизить без критичных дефектов! Серьезность (Severity) на дефектах у quality assurance инженеров должна иметь такую градацию (у уязвимостей она чуточку другая):
Цитируя автора книги Managing Information Technology Projects Джеймса Тейлора, «жизненный цикл проекта охватывает всю деятельность проекта». Задачей же разработки ПО является выполнение требований продукта. Если вы хотите научиться создавать и выпускать высококачественное ПО, вам придется следовать плану. Со слов Тейлора, вашей целью должен стать всесторонний анализ деятельности проекта и контроля каждого этапа его разработки. Вот только с чего именно начать?
Как работает SDLC?
Жизненный цикл разработки программного обеспечения состоит из семи этапов, описывающих, как следует разрабатывать программный проект. Хотя у каждого есть своё имя для каждой стадии SDLC, вот основные темы, которые вы увидите на протяжении жизненного цикла:
- Анализ и планирование.
- Дизайн.
- Развитие.
- Тестирование.
- Развёртывание.
- Обслуживание и оценка.
Давайте углубимся в каждый из этих этапов и обсудим, как они работают и как они применяются при разработке программного проекта.
В какой момент запускать сканирования?
При таком подходе мы еще и получаем бонус: разработчики, когда видят результаты SAST “каждый день”, продвигаются в знаниях безопасного программирования, таким образом в целом повышается культура безопасной разработки и код становится лучше.
Само собой, при внедрении SAST в процесс разработки необходимо внедрение в CI/CD, построение DevSecOps. Тренд переноса SAST с контрольных проверок перед релизом в процесс разработки виден давно, и в последние 2-3 года он догнал наш рынок. Сейчас ни один пилот не проходит без тестирований возможностей интеграции.
При этом я бы оставлял контрольные проверки перед релизом, в идеале, — по бинарным сборкам (такое тоже возможно). Так можно удостовериться, что никаких новых уязвимостей не было добавлено в процессе сборки и переноса приложения в продуктив.
Спиральная модель
Этот подход основан на оценке риска, он сочетает в себе функции каскадной, прототипной, итеративной и инкрементной моделей. Модель похожа на спираль с несколькими кругами. Каждый круг – это фаза, состоящая из четырёх элементов:
- Сбор требований. Он включает выявление и анализ потребностей заинтересованных сторон и бизнес-целей.
- Анализ рисков и прототипирование. Команда оценивает все возможные способы удовлетворения потребностей клиентов и выбирает лучшее решение. Затем они выявляют и устраняют риски, связанные с решением, и создают прототип, который развивается с каждым последующим циклом.
- Инжиниринг. Команда инженеров продолжает разработку и тестирование того, что было запланировано на двух предыдущих этапах.
- Планирование следующего этапа. Готовый продукт отправляется заказчику для получения обратной связи. Кроме того, команда разработчиков анализирует весь цикл с точки зрения расписания, бюджета и других критериев.
Затем, на основе отзывов пользователей и заинтересованных сторон, планируется следующая итерация.
Как видите, продукт неоднократно проходит через эти этапы, и в конце каждого цикла создаётся и выпускается лучшая версия продукта. И, как и в итеративном подходе, продукт состоит из серии релизов.
Плюсы | Минусы |
Анализ рисков на каждой итерации увеличивает шансы проекта на успех. | Требуется опыт управления рисками. |
Этот метод позволяет создавать стабильные и надёжные системы, поскольку они тщательно тестируются в каждом цикле. | Модель подразумевает работу с большим объёмом документации. |
Можно менять требования между циклами. | Нельзя изменить требования в середине цикла. |
Раннее вовлечение разработчиков помогает согласовать бизнес-требования и технические возможности. | Каждый кружок в спирали развития представляет собой «мини-каскад», а это значит, что вы не можете пропускать фазы. |
Частые выпуски позволяют получать регулярную обратную связь от клиентов даже на ранних этапах цикла. | Поскольку ограничений на количество итераций нет, сложно предсказать, сколько кругов потребуется для создания окончательной версии продукта. |
Модели гибкой разработки программного обеспечения
Вопреки распространённому мнению Agile не является ни структурой, ни методологией. Это философия с набором принципов, ориентированных на ускорение процесса разработки программного обеспечения, обеспечение 100% удовлетворённости клиентов и предоставление высококачественных решений в быстро меняющейся среде. Фактически, существует 12 принципов гибкой разработки, которые сводятся к следующим ценностям:
- Люди и взаимодействие важнее процессов и инструментов.
- Рабочее программное обеспечение над обширной документацией.
- Сотрудничество с клиентами вместо переговоров по контракту.
- Реагирование на изменения вместо следования плану.
Ценности Agile породили более 50 методологий , из которых Scrum является самой популярной .
Технические вопросы
А дальше приведу сразу 4 вопроса.
- Подключим SAST как SonarQube, в чем сложность?
- SAST работает долго, как настроить DevSecOps?
- SAST дает ложные срабатывания, как настроить Quality Gate?
- И без ложных срабатываний в отчете несколько тысяч уязвимостей, что с ними делать?
- Из-за экспоненциальной природы алгоритмов SAST может работать долго и потреблять много ресурсов — сильно больше, чем линтер или SonarQube.
- По той же причине SAST может давать довольно много ложных срабатываний — вряд ли разработчики захотят разбирать кучу фолзов каждый день после очередного скана.
- Обычно SAST запускается на кодовой базе впервые, и первый прогон может показать очень много срабатываний, особенно если кода много и база не очень новая.
Как применяется SDLC
Жизненный цикл разработки программного обеспечения может быть применён к программному проекту несколькими способами. Вы обнаружите, что нет двух одинаковых команд разработчиков. Каждый будет использовать свои собственные модели для реализации SDLC, сохраняя при этом лучшие практики, которые управляют этой моделью.
Давайте обсудим три из самых популярных моделей SDLC, используемых командами разработчиков программного обеспечения.
Этап 6: Обслуживание и оценка
Хотя планирование является важной частью SDLC, вы обнаружите, что потребности проекта со временем изменятся. Возможно, пользователи просят добавить другую функцию или обновить библиотеки, чтобы продукт по-прежнему работал с использованием новейших инструментов.
После публикации проекта вы будете отвечать за его поддержку. Часто разработчики используют инструменты мониторинга производительности приложений, чтобы убедиться, что их код работает эффективно. Если разработчики не поддерживают свои приложения, они могут стать нестабильными и перестать соответствовать исходным требованиям проекта. Это вредно для деловых отношений.
Зачем SAST, если уже есть бесплатные статические анализаторы?
Этот вопрос мы частично затронули в предыдущей части. Мы, конечно, ни в коем случае не умаляем заслуги открытых инструментов. Все знают SonarQube — прекрасный инструмент для автоматизации оценки качества кода, с большим количество поддерживаемых языков, интеграций и плагинов. SonarQube хорош для встраивания в процесс разработки, но предназначен больше для подсчета различных метрик кода и поиска достаточно простых ошибок или уязвимостей. В нем не реализован межпроцедурный анализ потока данных, соответственно, его нельзя использовать для поиска сложных уязвимостей. Обычно мы рекомендуем использовать как SonarQube, так и хороший SAST-тул (тут может быть полезно, если SAST-тул умеет интегрироваться с SonarQube).
Есть и другие хорошие открытые статические анализаторы. Можно назвать spotbugs (findbugs) для байткода JVM с плагином find-sec-bugs, в котором реализован внутрипроцедурный анализ потока данных с небольшим набором правил. Для Python есть известный анализатор bandit. Нельзя не упомянуть встроенный в clang статический анализатор, который обладает и хорошим движком анализа, и неплохой базой правил.
Проблемы таких инструментов в том, что обычно они довольно узко специализированы (например, подходят для одного языка), реализуют простые алгоритмы (то есть не позволяют находить сложные уязвимости), обладают сильно меньшими базами правил, чем коммерческие инструменты. Помимо этого они обладают меньшим набором функциональности, как интерфейсной, так и интеграционной. Ну и можно упомянуть отсутствие поддержки.
С другой стороны хорошие коммерческие SAST-тулы (а есть и нехорошие) реализуют сложные специфические алгоритмы и обладают обширными базами правил, которые могут насчитывать тысячи записей. Обычно они поддерживают много языков программирования, обладают богатыми возможностями интерфейса и интеграции (плагины, API). Ниже привожу пример, о каких интеграциях может идти речь.
А еще ниже посмотрите на пример схемы интеграции, которую можно построить на основе SAST-инструмента. В целом схема не отличается от внедрения других средств контроля качества кода. Разработчики пишут код и могут сразу запускать проверку SAST. Код попадает в репозиторий и оттуда по различным триггерам с помощью CI/CD попадает в SAST. Результаты сканирования можно либо смотреть в интерфейсе SAST, либо они могут попадать в средства, обеспечивающие процесс разработки (багтрекер, почту и т.п.).
Каскадная модель (waterfall)
Это линейная и последовательная модель разработки программного обеспечения, в которой фазы проекта следуют одна за другой и включают:
- Исследование. Группа разработчиков собирает требования к проекту и включает их в документ «Спецификации требований к программному обеспечению» (SRS).
- Дизайн. Команда анализирует все требования и выкатывает прототип системы.
- Кодирование. Как только заинтересованные стороны проекта согласовывают прототип, начинается фаза написания кода.
- Тестирование. Команда QA запускает каждый модуль через различные сценарии тестирования и интегрирует их в систему. Как только все компоненты на месте, они тестируют систему целиком.
- Развертывание. Решение доставляется заказчику в полностью рабочем состоянии.
- Обслуживание. Команда разработчиков следит за проектом и при необходимости вносит обновления.
V-образная модель SDLC
V-образная модель – это своего рода другая версия каскада, но в её основе лежит контроль качества каждой фазы. Например, когда группа разработчиков собирает требования к проекту, QA-специалисты пишут приемочные тесты на основе этих сценариев. Точно так же на этапе проектирования системы создаются сценарии тестирования и так далее. После написания кода команда QA проверяет продукт на соответствие заранее написанным тестам (правая часть буквы «V»).
Плюсы | Минусы |
Легко реализовывать. | В V-образной модели внести изменения в середине проекта крайне сложно. |
Тест-кейсы создаются заранее. | При таком большом количестве процедур тестирования остается меньше времени на код. |
Бюджет и продолжительность проекта предсказуемы. | По сравнению с каскадной эта модель требует больше специалистов. |
У каждого этапа есть свои результаты, и все хорошо задокументировано. | Модель не подходит для проектов с быстро меняющимися требованиями. |
Это структурированный подход с четко определенными ролями и функциями. | Не подходит для больших и сложных проектов. |
Каким проектам подходит
Спиральная модель подходит для:
- Больших, сложных продуктов, состоящих из нескольких компонентов.
- Проектов с частыми релизами.
- Проектов средней и высокой степени риска.
- Проектов с неясными требованиями.
Microsoft, IBM и Tata Consultancy используют спиральную модель.
Этап 4: Тестирование
Вы сделали тяжёлую работу, и функции, необходимые для создания, готовы, но вы ещё не закончили. Что делать, если ваш код содержит ошибки? Или что, если ваш проект не работает в данном пограничном случае?
Здесь вступает в игру фаза тестирования. Вам нужно будет определить, какие проблемы существуют в вашем коде, и создать решения этих проблем, чтобы конечный продукт соответствовал спецификациям, изложенным на этапе анализа.
Начнём
Этап 1: Анализ и планирование
Прежде чем вы сможете разработать проект или создать для него функцию, вам сначала нужно знать, что вы собираетесь построить. Какие особенности должен иметь проект? Каких функций у него не должно быть?
Хотя многие люди рассматривают разработку программного обеспечения как простое кодирование, на самом деле это гораздо больше, чем просто ввод кода. Вам нужно будет определить объём и границы проекта, прежде чем вы начнёте писать код. Здесь вы поймёте, что вы собираетесь построить и почему.
На этапе анализа и планирования вы будете работать со всеми заинтересованными сторонами проекта — от руководителей до других разработчиков и клиентов — чтобы обеспечить разработку соответствующих спецификаций проекта. Вам необходимо убедиться, что проект соответствует не только ожиданиям клиентов, но и целям вашего собственного бизнеса.
Объединяя все вместе: подход SDLC
Фреймворк SDLC существует для помощи в сокращении времени вывода продукта на рынок, обеспечении более качественной производительности, экономии бюджета и повышения потенциальной пользы вашего продукта для заинтересованных сторон, о которых вы заботитесь. Особенно хорошо SDLC помогает при разработке ПО, поскольку он заставляет вас трудиться в строгих рамках. Другими словами, для обеспечения корректных действий в корректное время и по корректным причинам SDLC заставит вас следовать каждому необходимому шагу. Думайте о SDLC как о плане по достижению успеха: слепое ему следование ничего вам не гарантирует, но повышает вероятность что вы останетесь довольны результатами.
Разработка ПО, как все мы с вами знаем, это тема обширная, и она может затрагивать вопросы от инструментов веб-дизайна и онлайн форм до более надежного машинного обучения или систем бэкенда. Пишете ли вы код в браузере или занимаетесь более надежной разработкой, план действий вам необходим.
Разработка ПО может быть трудным, и в то же время полезным занятием.
SDLC это план по ведению технических работ, но если смотреть шире, то можно воспринимать его как руководство по жизни. Применять SDLC можно к множеству тем, например, создание контента в SaaS модели ведется по циклу SDLC. Перед написанием контента автор сначала определяет требования, планирует, что именно он будет писать, и лишь затем фактически прикладывает перо к бумаге. Также SDLC отлично подходит для технологических предпринимателей.
Мой друг хотел основать лучшее рекламное агентство для Facebook и обратился ко мне и другим специалистам за помощью. Несмотря на его большие амбиции, я посоветовал ему воспользоваться фреймворком SDLC чтобы сначала провести анализ требований. Я спросил его: «Какие проблемы ты хочешь решать? Чего хотят твои пользователи? И самое главное, как эта платформа поможет тебе достичь твоих целей?»
Сформулировав эти вопросы вокруг SDLC, он смог лучше отточить свой финальный продукт и предоставить нужные инструменты правильным пользователям. Он сузил свой кругозор до более строгого определения его проблемной области и смог выделить ресурсы на планирование еще до того как он начал делать что-либо еще.
Затем он перешел к созданию самого лучшего сервиса по росту на Instagram, но его интересы постоянно развиваются, и сейчас уже есть программы-планировщики деятельности в социальных сетях в любом масштабе. И в итоге ему придется вернуться к основам: анализу требований.
Принятие пользователями его технологий доказывает, что при правильном применении SDLC можно достичь основательных технологических и финансовых результатов. Однако, как и при развитии бизнеса, разработка ПО никогда не заканчивается.
Следовательно, цикл продолжается.
Вне зависимости от того что вы создаете, компанию ли, инструмент, сложную программу либо полностью новый продукт, чтобы обеспечить качество и сосредоточиться на пользователях, хорошим решением будет взять на вооружение SDLC.
Фраза «Создавать круто» должна стать вашей путеводной звездой, а SDLC – инструментом и помощником.
В этой статье Вадим Кулага, проектный менеджер EPAM Anywhere, расскажет об основных моделях разработки программного обеспечения (SDLC), их плюсах и минусах, а также о реальных примерах их использования.
Более половины ИТ-проектов заканчиваются провалом. Одни из самых распространенных причин неудач ИТ-проектов – неправильная интерпретация бизнес-целей, игнорирование клиентов, неправильная расстановка приоритетов. Но у всех у них общий корень проблемы: неправильный подход к разработке программного обеспечения.
Заключение
Команды профессиональных разработчиков используют жизненный цикл разработки программного обеспечения, чтобы гарантировать, что участники не упустят из виду задачи, которые необходимо выполнить, например, тесты, которые необходимо запустить, или функции, которые необходимо создать. Жизненный цикл создаёт стандартный подход к разработке программного обеспечения. Поэтому каждый разработчик знает, что от него ожидается и когда. Всё это гарантирует, что проекты будут доставлены клиентам вовремя и в соответствии с ожиданиями.
С каждым годом культура разработки растет, появляются новые инструменты для обеспечения качества кода и новые идеи, как эти инструменты использовать. Мы уже писали про устройство статического анализа, про то, на какие аспекты анализаторов нужно обращать внимание, и, наконец, про то, как с организационной точки зрения можно построить процесс на основе статического анализа.
Отталкиваясь от вопросов, с которыми мы часто сталкиваемся, мы описали весь процесс внедрения сканера кода в процесс безопасной разработки. Сегодня речь пойдет о том, как выбрать подходящий вам анализатор.
Все разработчики так или иначе сталкиваются со статическим анализом (анализом кода без выполнения). Например, когда компилятор по результатам сборки выдает какие-то ошибки или предупреждения — это результаты статического анализа. Мы часто используем линтеры — это тоже статический анализ, хоть зачастую и очень простой. Есть и более интересные примеры — spotbugs (ранее — findbugs), который позволяет находить довольно интересные уязвимости в байткоде Java, или хорошо известный SonarQube — платформа для контроля качества кода.
Однако с полноценными SAST-инструментами пока мы сталкиваемся редко. В первую очередь мы говорим про тулы, которые могут находить сложные уязвимости. Как оказывается на практике, открытые известные инструменты не справляются с этой задачей, как минимум потому, что фокусируются на другой области (баги и простые уязвимости). Хороший SAST-тул реализует межпроцедурный анализ потока данных. Анализ должен проходить не на тексте программы, а на внутреннем представлении — CFG, AST и т.п. Про это подробнее лучше почитать в предыдущей статье.
Здесь приведем пример — всем известную SQL-инъекцию. В этом примере данные от пользователя попадают в функцию completed из запроса, передаются в функцию injectableQuery и уже там попадают в SQL-запрос, делая приложение уязвимым к SQL-инъекции.
Для того чтобы найти такую уязвимость, нужно понимать, откуда могут приходить “плохие” данные, как такие данные могут валидироваться, где их нельзя использовать. И самое важное — нужно отслеживать передачу данных по всему приложению, это и есть dataflow-анализ. Пример очень простой, в реальном же приложении данные могут пройти через множество функций и модулей, присваиваний и синонимов.
Понятно, что текстовый поиск не найдет такую уязвимость. Внутрипроцедурный анализ также не найдет, а в некоторых открытых инструментах только он и реализован. Чтобы находить такие уязвимости (а это обычно и есть самые критические уязвимости, то есть главная цель работы SAST-тула), нужны хорошо проработанные алгоритмы межпроцедурного анализа потока данных с большими базами правил.
Именно исходя из алгоритмической сложности возникает ряд технических вопросов, которые отличают внедрение SAST-инструмента от других статических анализаторов, например, SonarQube. Эти вопросы мы и обсудим в серии статей. Спойлер: потребление ресурсов, продолжительность анализа, ложные срабатывания.
Надо упомянуть, что помимо алгоритмов хороший инструмент оборачивает всю математику в удобную интерфейсную оболочку, позволяя использовать SAST без серьезной подготовки. Такие инструменты также встраиваются в CI/CD с помощью плагинов и API, таким образом автоматизируя поиск уязвимостей и позволяя строить процессы безопасной разработки.
В первой статье мы попытались классифицировать основные вопросы, которые возникают при изучении SAST, а также и после решения внедрить инструмент. О каких-то вопросах поговорим здесь, какие-то уйдут в следующие статьи.
Модель водопада
Модель водопада, пожалуй, самая распространённая реализация SDLC. С помощью этой модели вы переходите к следующему этапу цикла после завершения текущего этапа. Например, вы начнёте с анализа, а после его завершения перейдёте к этапу проектирования.
Эта модель полезна тем, что легко оценить прогресс. Однако у него есть и недостатки. Например, если вам нужно вернуться назад, потому что требования к программному обеспечению изменились, ваш конечный продукт может не соответствовать всем целям, если у вас нет систем для возврата и исправления кода, который может больше не иметь значения.
Каким проектам подходит
Каскадная модель – хороший вариант, если выполняются эти условия:
- Проект короткий и с нулевым риском.
- Требования фиксированные.
- Технологии стабильны.
- Доступны все необходимые ресурсы.
Всего десять лет назад многие компании использовали каскадную модель для разработки корпоративного программного обеспечения, включая CRM, системы управления цепочками поставок и системы точек продаж. Но сегодня эта модель не может удовлетворить быстро меняющиеся технические потребности. Вот почему компании все чаще обращаются к более современным подходам.
Принципы работы SDLC и почему им пользуются
На диаграмме ниже можно ознакомиться с шестью основными этапами SDLC.
На этом самом основном уровне вы сможете понять каковы должны быть требования к работникам в вопросах учета времени и труда, для чего полезно будет опросить как самих работников, так и их руководящих менеджеров. Так же для большего понимания проблем текущих приложений в области вы можете протестировать ваши решения на рынке, а создание диаграмм, графиков и в целом ведение записей поможет вам более глубоко понимать количественную и качественную обратную связь. Только после осознания этих критических особенностей вы будете готовы перейти к следующему этапу SDLC – планированию.
Фаза анализа требований может оказаться очень утомительной, но проходя через эти шаги, вы добиваетесь множества результатов: снижаете время выхода продукта на рынок, обеспечиваете большую его производительность, экономите бюджет и повышаете вероятность вхождения продукта на рынок.
Мыслите за пределами обычного приложения по отслеживанию времени — думайте о том, что вы хотите создать, чем вы хотите заниматься, а затем определите требования для решения связанных с этим проблем. Это и будет вашим началом.
Этап 3: Разработка
После планирования и проектирования вы готовы приступить к разработке. Здесь вы откроете терминал и текстовый редактор, чтобы начать работу над проектом. Вы потратите много времени на создание всех функций, согласованных в ходе предыдущих обсуждений.
Разработка — это не только написание кода. На этом этапе вам необходимо встретиться с другими разработчиками, чтобы распределить работу и обсудить, кто лучше всего подходит для решения конкретных проблем. Скорее всего, вы разработаете процесс, который поможет вам эффективно писать код в команде.
Продолжение следует
Внедрять SAST — надо, обычно это оправдано. Но, приступая к внедрению, хорошо бы ознакомиться со всеми подводными камнями, которые возникнут на вашем пути. В этой статье мы начали их разбирать, продолжим техническими аспектами в следующей.
Все наши приложения так или иначе могут быть подвержены уязвимостям. Это, в свою очередь, может привести к финансовым потерям и спровоцировать утечку данных клиентов.
Зачем и от чего защищаться? Какие инструменты для этого существуют, в том числе Open Source? Что такое Secure Software Development Lifecycle? Александр Киверин — технический директор в Ак Барс Цифровые Технологии — рассказал об опыте своей компании на TechLead Conf 2020 Online. А мы подготовили расшифровку.
Зачем защищаться? На этот вопрос есть понятный ответ: уязвимость приложений может принести репутационные или финансовые риски компании (а, возможно, и те, и другие). Поэтому безопасность важна для всех. А от чего стоит защищаться?
У разрабатываемых нами, инженерами, приложений есть несколько точек, где чаще всего прячутся уязвимости:
Инъекции – SQL, LDAP, XPath;
Небезопасная передача информации;
Некорректная обработка ошибок;
Cross-Site Scripting (XSS);
Cross Site Request Forgery (CSRF);
Ошибки в контроле доступов;
Некорректная аутентификация и управление сеансами.
Гибкая модель
В гибкой модели используется циклический подход к разработке программного обеспечения. Это означает, что работа выполняется циклами, известными как спринты, которые обычно длятся от двух недель до месяца.
Agile поддерживает итеративную разработку. Это означает, что, если вы поймёте, что продукт не соответствует своим начальным спецификациям. Вы можете легко вернуться к этапу проектирования и внести необходимые изменения. Эти изменения будут внесены в следующем спринте.
Инкрементальная модель технически является частью модели водопада. Это серия водопадных циклов. В этой модели разработчики объединяются в группы и разделяют требования к проекту. Затем каждая группа реализует согласованный SDLC.
Это хорошая модель для использования, когда вы работаете над большим проектом с множеством требований, поскольку она может помочь вам разбить то, что необходимо для продвижения общего развития проекта.
Существуют и другие модели, такие как модель большого взрыва, спиральная модель и v-модель. Однако три модели, которые мы только что обсудили, являются наиболее распространёнными.
Каким проектам подходит
Модель будет эффективна в следующих случаях:
- Если система состоит из нескольких сегментов с чёткими требованиями.
- Ограниченные ресурсы на проекте или есть ограничения по времени выхода решения на рынок.
- Для стартапов, проходящих инвестиционные раунды.
- Масштабные проекты.
- Проекты, в основе которых новые технологии.
- Проекты, которые потребуется развивать после выпуска.
По словам Алистера Скотта , каждый программный продукт, который хочет оставаться конкурентным на рынке, требует наращивания мощностей. Даже если вы будете использовать каскадную модель для разработки своего решения, к моменту завершения цикла решение уже устареет. Поэтому необходимы дополнительные итерации.
Этап 5: Развёртывание
Готовый продукт готов. Вы протестировали код и убедились, что конечный продукт соответствует всем исходным спецификациям. Теперь вы готовы начать развёртывание проекта.
Здесь вы перенесёте разработанное вами программное обеспечение из среды тестирования в рабочую среду. Например, с помощью веб-приложения вы можете переместить свой код на работающий веб-сервер, на котором размещён ваш веб-сайт; с игрой вы можете опубликовать свой код в игровом магазине.
Scrum
Скрам-проекты разбиты на спринты. Спринт – это небольшой объём работы, который необходимо выполнить в течение определённого периода времени. Обычно заказчику доставляется часть проекта, которая была завершена во время спринта (инкремент продукта, от англ. increment). Скрам подразумевает активное общение и сотрудничество между всеми участниками проекта. Наряду с ежедневными 15-минутными встречами разработчиков, есть также:
- Планирование спринта , когда заинтересованные стороны проекта и команда разработчиков встречаются, чтобы обсудить, что нужно сделать во время следующего спринта.
- Обзор спринта , когда команда разработчиков демонстрирует заинтересованным сторонам, что было сделано во время спринта, и анализируется прогресс в достижении цели проекта.
- Ретроспектива спринта , когда команда разработчиков анализирует спринт и обсуждает, как можно улучшить процессы во время следующих спринтов.
Сердце процессов Scrum – это backlog, своего рода список задач, которые необходимо сделать для завершения проекта. По мере того, как проект продвигается, и команда узнаёт о нём больше, они редактируют бэклог продукта, добавляя, удаляя и переупорядочивая его элементы. Тем не менее, нельзя сделать что-то, если этого нет в очереди продукта.
Но на самом ли деле всё так гладко и красиво в Agile? Посмотрим на его основные варианты использования, а также на плюсы и минусы.
Плюсы | Минусы |
Не нужно ждать завершения проекта, чтобы внедрить основные функции продукта. | Гибкие методологии разработки ПО сложно внедрить. |
Кросс-функциональные команды регулярно общаются и обмениваются знаниями между собой и владельцами проектов. | В Agile проектная документация очень быстро устаревает, поэтому понадобятся дополнительные навыки оперативной работы с ней. |
Возможность адаптироваться к изменениям на любой стадии проекта. | В Agile проектах практически невозможно делать прогнозы и достаточно тяжело с высокой долей точности планировать бюджет. |
Регулярная обратная связь от пользователей, что позволяет удовлетворить все потребности. | Сбор отзывов пользователей может быть сложной задачей. |
Какой SAST-тул выбрать?
Немного остановлюсь на этапе выбора инструмента. SAST-тулов довольно много, на рынке обычно представлено несколько штук (3-4). Возникает вопрос, как выбрать нужный инструмент, на что обращать внимание? Тут не буду удивлять, остановлюсь на трех пунктах: функциональное сравнение, сравнение по качеству и лицензирование. Важно взять инструмент на тестирование (пилот) в свой локальный контур и проверять на своем коде в своей инфраструктуре.
Хорошо бы попробовать все фичи интерфейса, понять, насколько они применимы к вашему кейсу и насколько ими удобно пользоваться. Отсылаю к одной из предыдущих статей. Приведу несколько полезных фич:
- максимально автоматизированный запуск сканирования (в идеале, без лишних настроек в две кнопки можно запустить скан);
- возможность анализа разных типов приложений — исходный код, бинарный код, несколько языков в одном файле;
- исключение директорий из анализа;
- инкрементальный анализ;
- добавление своих правил поиска уязвимостей;
- сравнение сканирований (качественное, то есть отслеживание уязвимостей между сканами одного проекта);
- редактирование результатов сканирования с отслеживанием результатов редактирования между сканированиями одного проекта;
- понятные описания уязвимостей, желательно с трассой анализа потока данных для уязвимостей типа “внедрение”;
- наличие метрики “уверенность тула в том, что он нашел не ложное срабатывание”;
- гибкое администрирование;
- широкие и удобные в использовании аналитические функции.
Для проверки качества нужно просканировать ваш код. Хорошо выбрать несколько разных примеров на разных языках, чтобы выборка была репрезентативна. С точки зрения качества нужно смотреть на ложные срабатывания (там, где явно нет уязвимости, а тул показывает) и на пропуски (в идеале нужно знать, где есть уязвимости, ну или сравнивать найденные уязвимости в разных тулах). Я бы чуть меньше внимания обращал на ложные срабатывания, так как обычно достаточно один раз пройтись по результатам сканирования, пометить ложные, и дальше они не будут беспокоить вас.
Остановлюсь на двух важных моментах. Во-первых, очень важно смотреть на все это в применении именно к вашей ситуации. Проверять именно ваш код (SAST может по-разному работать на разных типах приложений). Искать те фичи, которые нужны вам для встраивания тула в процесс разработки. Проверять интеграции с системами, которые у вас есть.
Во-вторых, очень важно во время пилота общаться с вендором. SAST — не самая простая штука, и часто достаточно получить обычную консультацию от вендора, чтобы оценить в полную силу мощь инструмента.
Итеративная и инкрементальная модель
В инкрементальной и итеративной модели решение разрабатывается небольшими частями через серию циклов. Рабочий процесс выглядит следующим образом:
- Планирование. Собираются все требования к проекту и делятся на составляющие.
- Реализация модулей. Каждая итерация представляет собой «мини-каскад», который имеет такой же процесс: анализ требований модуля, проектирование, реализация и тестирование модулей, интеграция и тестирование всей системы, выпуск версии и оценка. Процесс повторяется до тех пор, пока не будут выполнены все требования.
Плюсы | Минусы |
Модель инкрементальной и итеративной разработки обеспечивает быструю и регулярную «доставку» работающего программного обеспечения клиентам. | Во время интеграции модуля могут возникнуть архитектурные проблемы. |
Легче и дешевле учесть изменения в требованиях проекта. | Несмотря на некоторую гибкость, систему следует планировать с самого начала; в противном случае его нельзя разделить на модули. |
Обратная связь от клиента на ранней стадии. | Участие клиентов может быть проблематичным. |
Небольшие части программного обеспечения легче тестировать и исправлять. | Не всегда можно разбить систему на сегменты. |
Экономия на издержках. | Хотя выпуск одного модуля дешевле, общие затраты на систему будут увеличиваться по мере интеграции новых модулей. |
Каким проектам подходит
V-образная модель может быть чрезвычайно полезна в случаях, когда ошибки могут быть фатальными, и в проектах, где точность имеет решающее значение. Например, это решение, основанное на нормативных требованиях, таких как подача налоговых деклараций. Кроме того, эта модель подходит для проектов в сфере здравоохранения. Например, компания Roche Diagnostics однажды использовала его для разработки системы диагностики рака.
Основные методологии разработки ПО
Методология разработки программного обеспечения (SDLC) представляет собой последовательность действий, которые необходимо выполнить, чтобы получить готовое решение. Проще говоря, это способ создания программного продукта. Проблема в том, что существует множество моделей SDLC, которые используются для разных типов проектов. Как узнать, какой из них подходит для вашего проекта? В статье я перечислил наиболее популярные модели SDLC, их варианты использования, преимущества и недостатки.
Резюме
Ни одна из моделей SDLC не является «волшебной пилюлей». Нельзя просто выбрать методологию, которая соответствует потребностям проекта, и слепо следовать ей. В лучшем случае это не улучшит ваш процесс разработки. В худшем вы подвергнете риску проект. Вот почему грамотный подход к выбору и реализации модели разработки программного обеспечения является ключом к тому, чтобы заставить её работать на вас.
Вот несколько советов как подходить к разработке на примере реального проекта EPAM Anywhere :
Модель эволюционного прототипирования
Это ещё одна вариация каскада. Пока проект проходит через традиционные фазы, прототип продукта пошагово дорабатывается на основе отзывов клиентов. Как правило, первый прототип не проходит приемочный тест, поэтому модель прототипирования включает в себя несколько прототипов. Только после того, как предложенный дизайн продукта будет полностью принят, команда разработчиков сможет перейти к следующим этапам.
Плюсы | Минусы |
Получение отзывов пользователей на ранних этапах. | Поскольку прототипы могут развиваться бесконечно, планирование проекта невозможно. |
Высокие шансы на успех проекта. | Разрабатывать несколько прототипов – дорого. |
Легко адаптироваться к быстро меняющимся требованиям. |
Организационные вопросы
Я бы не стал забывать и про организационные вопросы. В больших компаниях их возникает немало, от самого процесса внедрения, выделения ресурсов до создания регламентов и тиражирования процессов.
Организационные вопросы порождаются теми же техническими особенностями, которые мы обсуждали в предыдущем пункте. Ну а помимо этого пока никуда не девается исторически сложившееся разделение и противостояние разработки и безопасности. Также отсылаю к предыдущей нашей статье.
Каким проектам подходит
Модель эволюционного прототипирования может быть полезна для проектов, которые предполагают взаимодействие с пользователем, используют новые технологии, имеют сложную функциональность или должны учитывать быстро меняющиеся требования, которые трудно или невозможно предсказать.
Плюсы и минусы подхода
Плюсы | Минусы |
Простая в использовании модель. | С этой моделью слишком сложно и дорого адаптироваться к изменениям требований. |
Каждый этап хорошо задокументирован. | Документирование каждой фазы проекта занимает много времени. |
Результат проекта абсолютно предсказуем. | Вы не можете ничего предоставить заказчику, пока не завершите весь проект. |
Этапы и роли четко определены с самого начала. | Различные команды (дизайн, разработка, контроль качества и т. д.) изолированы, а взаимодействие между ними ограничено. |
Минимальное вмешательство клиента. | Без обратной связи клиента результат рискует не оправдать ожидания. |
Примеры использования
Большинство современных проектов требуют определённого уровня «маневренности», особенно когда:
- Требования к проекту недостаточно ясны.
- Требования к проекту постоянно меняются.
- Проект включает в себя множество взаимодействий с пользователем.
- У проекта много заинтересованных сторон.
В общем, Agile кажется именно тем, что нужно большинству проектов во времена неопределённости. Неудивительно, что более 70% компаний применяют Agile , включая Microsoft, IBM, Procter & Gamble и другие. И EPAM не исключение.
Что такое SDLC?
Жизненный цикл разработки программного обеспечения — это методология, которая описывает, как вам следует подходить к разработке программного обеспечения. Этот процесс гарантирует, что вы создаёте программное обеспечение в правильном порядке, и помогает сделать разработку более эффективной.
Жизненный цикл разработки программного обеспечения важен при разработке проекта, потому что он позволяет каждому в команде проекта — от менеджеров до разработчиков — отслеживать проект. Членам команды нужно только понимать основы жизненного цикла, чтобы получить точное представление о ходе проекта и о том, когда его части или все будут завершены.
Жизненный цикл разработки программного обеспечения полезен, потому что он чётко определяет, какие действия происходят на определённых этапах процесса разработки. Если вы новичок в программировании, очень полезно иметь чёткое представление о том, что вам нужно делать и когда, а также какие результаты должны быть получены и когда.
Жизненный цикл разработки программного обеспечения обычно контролируется менеджером проекта, который обеспечивает достижение разработчиками своих целей.
SSDLC
«Думайте о безопасности на всех этапах жизненного цикла разработки ПО, с самого начала».
SDLC — Software Develop Life Cycle — это жизненный цикл разработки ПО, который включает следующие этапы:
проработка требований или анализ;
непосредственно сама разработка;
Соответственно, Secure SDLC — это забота о безопасности на каждом этапе.
На этапе проработки требований нужно сделать оценку рисков. На этапе разработки архитектуры — архитектурное ревью, моделирование угроз. На этапе разработки — проверку анализаторами.
После чего стоит сделать тестирование безопасности. А во время деплоя позаботиться о правильной конфигурации приложений.
Этап 2: Дизайн
Итак, у вас есть план того, что вы хотите построить. Теперь вы должны спросить себя: как мы выполним этот план? Как мы собираемся создавать выявленные нами особенности?
Следующим этапом SDLC является этап проектирования. Именно здесь вы будете решать, как должны быть реализованы функции. Работая со всеми заинтересованными сторонами, чтобы ваши планы соответствовали их потребностям.
Работа с другими важна на каждом этапе SDLC, но особенно на этапе проектирования. Вы можете понять, что вам нужно создать, но, если вы не получите мнение всех заинтересованных сторон, ваш дизайн может не соответствовать всем требованиям.
Читайте также: