Жизненный цикл разработки ПО (англ. SDLC – Software development lifecycle) – это серия из шести фаз, через которые проходит любая программная система.
51 900 просмотров
Абсолютно любое ПО проходит через 6 основных шагов, начиная от простой идеи и заканчивая использованием её конечным пользователем.
Но как это выглядит изнутри? С какими сложностями сталкивается команда разработчиков и как их решает на каждой фазе Жизненного Цикла ПО? Об этом расскажет Павел Гапонов, Project Manager компании-разработчика SolveIt.
Типичный жизненный цикл разработки состоит из следующих фаз:
1. Сбор и анализ требований (Planning and Requirement Analysis)
Это, пожалуй самый ответственный и важный из всех шагов к созданию успешной программной системы. Вся собранная информация используется для планирования базового проектного подхода.
Дополнительно идет планирование требований по обеспечению качества и выявления различных рисков, связанных с проектом. Результатом анализа является определение различных технических подходов, которые можно использовать для успешной реализации проекта с минимальными рисками. Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода ко второму этапу.
Жизненный цикл IT проекта
Проблема: Не соответствующие ожидания и часто изменяющиеся требования: заказчик и команда не понимают, какую реально пользу принесёт продукт.
Решение: Определить скоп работ, согласовать четкий, краткий документ с требованиями, создать прототипы (макеты) для подтверждения и уточнения окончательных требований.
2. Документирование требований (Defining Requirements)
Как только базовый анализ требований будет выполнен, следующим шагом будет четкое определение и документирование требований к продукту, утверждение со стороны клиента. Если одной из целей первого этапа является понимание и анализ требований, то на этом этапе все цели должны быть прописаны, это защита обеих сторон.
Важно четко определить и прописать, что требуется выполнить, это делается с помощью SRS (Software Requirement Specification). Документ содержит все требования к продукту, которые должны быть спроектированы и разработаны в течение жизненного цикла проекта.
Проблема: Большой многостраничный список требований
Решение: Выяснить высокоуровневые требования и, в ходе разработки и коммуникации с заказчиком, дописывать ТЗ. То есть разработка идет параллельно с Техническим заданием, а в процессе корректируется план.
В SolveIt мы всегда стараемся быть гибкими и подстраиваться под клиента. Работающий продукт важнее исчерпывающей документации.
Павел Гапонов, Project Manager, SolveIt
3. Дизайн (Design the Product Architecture)
SRS это ориентир для разработчиков, чтобы предложить лучшую архитектуру для продукта. Обычно предлагается несколько подходов к проектированию архитектуры продукта. Все предложенные подходы документируются в спецификации DDS (Design Document Specification) и выбирается наилучший подход к проектированию. Данный подход очень четко определяет все архитектурные модули продукта, а также его связь с внешними и сторонними модулями.
Жизненный цикл разработки. SDLC (2020)
Проблема: Выбрали неправильную архитектуру.
Решение: Наличие в команде разработчиков опытных лидов, которые смогли бы предложить подходящую архитектуру, на основе своего успешного опыта в схожих проектах.
4. Разработка ПО (Building or Developing the Product)
Здесь начинается разработка и сборка продукта. Весь программный код, новые модули и фичи разрабатываются на основании DDS. Чем лучше написана эта документация, тем быстрее будет идти имплементация. На этом этапе подключается команда разработчиков.
Написанный код должен покрываться Unit-тестами, а взаимодействие новых фич с другими модулями тестироваться с помощью интеграционных тестов. Эти активности выполняются именно командой разработчиков, а не QA специалистами.
Проблема №1: Слабая коммуникация между командой
Разработчик не интересуется прогрессом проекта, проблемами коллег.
Решение: Daily meetings, 100% вовлеченность, Скрам доска (интерактивность).
Проблема №2: Невыполнимые сроки
Заказчик хочет, чтобы его продукт был готов в ближайшее время. Менеджер проекта пытается объяснить клиенту к чему приведет такая спешка, но этого не достаточно. Клиент ставит невыполнимые дедлайны и не слушает возражения менеджера проекта. В результате, команда разработчиков сдается и пробует закрыть задачи в слишком короткие сроки. Как следствие – критические баги из-за спешки: команда не успевает, качество продукта снижается, клиент не доволен и решает, что виновата команда.
Решение: Менеджер проекта должен стоять на своём и аргументировать дедлайны. Клиент должен понять, что если команда разработчиков будет торопиться, то не реализует часть функционала. Если всё же такой срок реализации критичен для клиента, мы стараемся выявить какие задачи находятся у заказчика в приоритете.
Проблема №3: Добавление не оговоренных фич
99% заказчиков ошибаются именно в этом месте . В ходе разработки клиент отклоняется от оговоренного тз и хочет добавить ещё фич в продукт. В результате вместе с ростом скопа фич, увеличиваются сроки и бюджет на разработку, деньги заканчиваются, а готово только 50% продукта.
Решение: Менеджер проекта должен объяснить клиенту, к чему приведет добавление новых фич в проект, отстаивать свою позицию и держаться SRS. Поэтому так важна вторая фаза Жизненного цикла разработки ПО.
5. Тестирование (Testing the Product)
Именно тестирование, в основном, затрагивает все этапы жизненного цикла. Дефекты продукта регистрируются, отслеживаются, исправляются и повторно тестируются. Это происходит до тех пор, пока продукт не достигнет стандартов качества, которые прописаны в SRS. На данном этапе в процесс разработки подключается команда мануальных тестировщиков или автоматизаторы.
Проблема: Тратится слишком много времени на поиск причин багов. Попытки найти и исправить дефекты после завершения разработки – сложный процесс, который может привести к большому количеству исправлений.
Решение: Проводить тестирование параллельно задачам, сразу же по их завершению.
6. Внедрение и поддержка продукта (Deployment in the Market and Maintenance)
Как только продукт протестирован, он выходит в релиз. Иногда внедрение происходит поэтапно, в соответствии с бизнес-стратегией. Продукт сначала может быть выпущен в ограниченном сегменте и протестирован в реальной бизнес-среде, это UAT-тестирование (User Acceptance Testing). Затем, основываясь на отзывах, продукт может быть выпущен как есть, или с предлагаемыми улучшениями. После того, как продукт выпущен на рынок его обслуживание выполняется для существующей клиентской базы, и на этом этапе подключаются Support-команды.
Проблема №1: Отсутствие обратной связи, реальных отзывов потенциальных пользователей продукта.
Решение: Не ждать конца разработки, а как можно скорее запускать продукт, чтобы получить отзывы от реальных пользователей и на основе их предпочтений приоритезировать дальнейший функционал.
Проблема №2: Слабая инфраструктура проекта на стороне клиента.
Часть заказчиков предпочитают размещать сервера приложений не на Azure, AWS, Google и т.д, а в своей внутренней сети. Команда не может гарантировать стабильную работу, из-за сбоев, которые происходят на стороне клиента.
Решение: Предупредить клиента, о возможных проблемах, предложить решения для их устранения.
Это шесть основных стадий жизненного цикла разработки системы, и это повторяющийся процесс для каждого проекта . Важно отметить, что должен поддерживаться отличный уровень коммуникации с заказчиком. Для реализации требований очень важны и полезны прототипы. Строя систему короткими итерациями, можно гарантировать соответствие требованиям потребителя до того, как построить целую систему.
Если вам нужен качественный продукт, свяжитесь с нами и мы сделаем оценку вашего проекта!
Источник: vc.ru
Жизненный цикл программного обеспечения
Жизненный цикл – это модель создания и использования программной системы. Он отражает различные состояния программной системы, начиная с момента возникновения необходимости в этой программной системе и принятия решения о ее создании и заканчивая полным изъятием программной системы из эксплуатации.
Международный стандарт ISOIES 12207 регламентирует структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания программного обеспечения. По этому стандарту жизненный цикл программного обеспечения базируется на трех группах процессов:
- основные процессы жизненного цикла, то есть приобретение, поставка, разработка, эксплуатация и сопровождение;
- вспомогательные процессы, обеспечивающие выполнение основных процессов, то есть документирование, верификация, аттестация, оценка качества и другие;
- организационные процессы, то есть управление проектами, создание инфраструктуры проекта и обучение.
- анализ требований заказчика;
- проектирование;
- реализация (программирование).
Модели жизненного цикла программного обеспечения
Существует несколько моделей жизненного цикла, которые определяют порядок исполнения этапов разработки и критерии перехода от этапа к этапу. К настоящему времени наибольшее распространение получили две модели жизненного цикла: каскадная и спиральная. В существующих ранее однородных информационных системах каждое приложение представляло собой единое целое. Для разработки таких приложений применялась каскадная модель жизненного цикла, которую также называют классической или водопадной. При использовании каскадной модели разработка рассматривалась как последовательность этапов, причем переход на следующий более низкий этап происходит только после того, как полностью завершены все работы на текущем этапе. Подразумевается, что в каскадной модели разработка начинается на системном уровне и происходит через анализ, проектирование, кодирование, тестирование и сопровождение. 
Рисунок 1– Основные этапы разработки каскадной модели 1. Системный анализ задает роль каждого элемента в компьютерной системе и взаимодействие элементов друг с другом. Поскольку программное обеспечение рассматривается как часть большой системы, то анализ начинается с определения требований по всем системным элементам. Необходимость системного анализа явно проявляется, когда формируется интерфейс программного обеспечения с другими элементами, т.е. с аппаратурой или базами данных. На этом же этапе начинается решение задач планирования проекта. В ходе планирования проекта определяется объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ. Анализ требований относится к отдельному программному элементу. На этом этапе уточняются и детализируются функции каждого элемента, его характеристики и интерфейс. На этом же этапе завершается решение задачи планирования проекта. 2. Проектирование состоит в создании:
- архитектуры программного обеспечения;
- модульной структуры программного обеспечения;
- алгоритмической структуры программного обеспечения;
- структуры данных;
- входного/выходного интерфейса (входных/выходных форм данных).
При решении задач проектирования основное внимание уделяется качеству будущего программного продукта. 3. Кодирование или разработка состоит в переводе результатов проектирования в код программы. 4. Тестирование – это выполнение программы на выявление дефектов в функциях, логике и форме реализации программного продукта. 5. Сопровождение – это внесение изменений в эксплуатируемое программное обеспечение с целью:
- исправления ошибок;
- адаптации к изменениям внешней для программного обеспечения среды;
- усовершенствование программного обеспечения в соответствии с требованиями заказчика.
Достоинства применения каскадной модели:
- дает план и временной график по всем этапам проекта, упорядочивая, таким образом, ход разработки;
- на каждом этапе формируется законченный набор проектной документации, проверенный на полноту и согласованность;
- выполняемые в логической последовательности этапы работы позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадная модель хорошо себя зарекомендовала при построении информационных систем, для которых в самом начале разработки можно достаточно точно сформулировать все требования в системе, например, сложные расчетные системы, различные системы реального времени и т.д. Недостатки каскадной модели:
- реальные проекты часто требуют отклонений от стандартной последовательности шагов;
- каскадная модель основана на точной формулировке исходных требований к программному обеспечению, однако реально в ряде случаев в начале проекта требования заказчика определены только частично;
- результаты реализации проекта доступны заказчику только после завершения всех работ.
Из-за необходимости в процессе создания программного обеспечения постоянного возврата к предыдущим этапам и уточнения или пересмотра ранее принятых решений реальный процесс разработки программного обеспечения на основе каскадной модели может быть представлен следующей схемой (рис.2). 
Источник: studfile.net
SDLC Жизненный цикл разработки ПО
SDLC – это жизненный цикл разработки программного обеспечения (Software development lifecycle). Он представляет собой несколько этапов (или фаз), которые проходит любое ПО. По сути, это подробный план, показывающий, как разрабатывать программное обеспечение, поддерживать его, изменять, улучшать.
SDLC и методологии разработки
Часто с этой аббревиатурой ассоциируют методологии разработки. Их существует немало. Подходящая выбирается исходя из масштабов проекта, характера требований к готовому продукту, стабильности используемых технологий, доступности необходимых ресурсов, с учетом ряда других факторов.
В настоящее время распространены следующие модели:
- Каскадная (waterfall). Простая в реализации, подходит для коротких проектов с нулевым риском и фиксированными требованиями.
- V-образная. Базируется на каскадной. Эта модель SDLC подразумевает контроль качества на каждом из этапов. Подходит для проектов, для которых ошибки могут иметь фатальные последствия, когда критически важна точность выполнения требований.
- Модель эволюционного прототипирования. Опять же, в основе – waterfall. При прохождении каждого этапа сразу же происходят необходимые доработки проекта на основе отзывов клиента (заказчика). Создается несколько прототипов, один из которых в итоге дорабатывается и отправляется в продакшн.
- Итеративная и инкрементальная. Решение разрабатывается модулями при реализации серии циклов. А при работе над каждым модулем используется все та же каскадная модель.
- Спиральная. Включает в себя черты предыдущих. Используется для сложных, крупных проектов с частыми релизами, подходит для ПО с неясными требованиями.
- Гибкие методологии. Их более 50. И многие, опять же, могут включать черты рассмотренных выше.
Учитывая, что многие модели, использующиеся в жизненным цикле разработки, содержат элементы каскадной, при рассмотрении вопросов безопасности целесообразно взять за основу ее.
Этапы SDLC и меры для обеспечения безопасности приложений на каждом из них
В жизненном цикле разработки ПО можно выделить 6 основных этапов:
- Анализ, составление требований к продукту.
- Планирование.
- Проектирование и дизайн.
- Разработка.
- Тестирование.
- Развертывание, эксплуатация.
Безопасная разработка программного обеспечения на каждом из этапов: какими средствами реализуется
На первом, втором и третьем этапах формируются бизнес-требования к продукту, учитываются пожелания и потребности пользователей, определяются границы проекта. К работе привлекаются специалисты из разных сфер (маркетинг, продажи, поддержка и так далее). В результате всех этих усилий должны появиться ответы на вопросы: «Какие проблемы должно решать ПО?», «Что именно (какой продукт) необходимо сделать?»
Одновременно на этой стадии должны продумываться и вопросы обеспечения безопасности, в частности в отношении идентификации, аутентификации, регистрации событий информационной безопасности (далее – ИБ), защиты инцидентов ИБ, контроля полноты, точности и правильности обрабатываемых данных. Это реализуется с помощью оценки угроз, анализа поверхности атаки, определения требований безопасности и анализа рисков. На данных этапах необходимо опираться на такие документы, как стандарт ISO 31010, разработанная ФСТЭК «Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных», а также другие документы (международные, национальные, отраслевые).
Начиная с этапа разработки SDLC для тестирования приложения безопасность обеспечивается с помощью:
- применения практик безопасного программирования,
- проведения автотестов,
- динамического анализа кода,
- организации пентестов (испытаний на проникновение),
- функционального тестирования,
- тестирования протоколов,
- мониторинга угроз, реагирования на инциденты (после развертывания, в ходе эксплуатации).
Также довольно распространенный инструмент для обеспечения безопасной разработки программного обеспечения, который может применяться на всех этапах (начиная с четвертого для рассматриваемого случая), – это статический анализ приложений (SAST). Он сводится к анализу программного кода без необходимости запуска программы, а значит, гарантированно подходит для этапов разработки, тестирования, развертывания и эксплуатации.
Статический анализ кода реализуется с помощью специального инструмента – SAST-анализатора. Эта технология позволяет:
- Выявлять уязвимости. Причем не только в «собственных» файлах приложения, но и в библиотеках и сторонних компонентах, которые используются при разработке.
- Находить недекларированные возможности (НДВ) в программном обеспечении.
Solar appScreener, как один из SAST-анализаторов, может проводить анализ исполняемых файлов с помощью эффективных технологий декомпиляции и деобфускации.
Посредством SAST-анализа можно организовать контроль безопасности приложений, написанных с использованием разных языков программирования. Он не требует серьезных вычислительных мощностей и серьезных временных трат (можно не выделять отдельное время, а тестировать ПО параллельно разработке или эксплуатации).
Еще одна особенность некоторых SAST-инструментов – относительная простота использования. Для работы с ними и интерпретации результатов не нужна команда разработчиков. С этим без проблем справится офицер службы безопасности или представитель другого отдела (в зависимости от специфики компании и процессов в ней). Можно организовать постоянный контроль безопасности программного обеспечения даже после сдачи и завершения гарантийного срока эксплуатации. Компании-пользователи могут реализовать это своими силами.
При добавлении к каждому этапу мер обеспечения безопасности можно говорить о трансформации SDLC в SSDLC. Это – Secure Software development lifecycle. Такой подход становится все более популярным, ведь реализация мер безопасности на протяжении всех этапов жизненного цикла – это хорошая практика, позволяющая сэкономить немало времени.
Источник: rt-solar.ru