Что такое Жизненный Цикл Разработки ПО и какие проблемы возникают на каждом этапе SDLC?
Жизненный цикл разработки ПО (англ. SDLC – Software development lifecycle) – это серия из шести фаз, через которые проходит любая программная система.
39 297 просмотров
Абсолютно любое ПО проходит через 6 основных шагов, начиная от простой идеи и заканчивая использованием её конечным пользователем.
Но как это выглядит изнутри? С какими сложностями сталкивается команда разработчиков и как их решает на каждой фазе Жизненного Цикла ПО? Об этом расскажет Павел Гапонов, Project Manager компании-разработчика SolveIt.
Типичный жизненный цикл разработки состоит из следующих фаз:
1. Сбор и анализ требований (Planning and Requirement Analysis)
Это, пожалуй самый ответственный и важный из всех шагов к созданию успешной программной системы. Вся собранная информация используется для планирования базового проектного подхода.
Дополнительно идет планирование требований по обеспечению качества и выявления различных рисков, связанных с проектом. Результатом анализа является определение различных технических подходов, которые можно использовать для успешной реализации проекта с минимальными рисками. Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода ко второму этапу.
Жизненный Цикл ПО. Уроки по тестированию. Обучение Junior qa
Проблема: Не соответствующие ожидания и часто изменяющиеся требования: заказчик и команда не понимают, какую реально пользу принесёт продукт.
Решение: Определить скоп работ, согласовать четкий, краткий документ с требованиями, создать прототипы (макеты) для подтверждения и уточнения окончательных требований.
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
Разработка ПО и стадии жизненного цикла программного обеспечения
Под этой стадией понимают разработку внутренней архитектуры продукта, а не внешний дизайн. Важно, чтобы архитектура ПО способствовала реализации всего функционала, возложенного на сам программный продукт. Поэтому всегда предлагают несколько архитектурных вариантов, чтобы можно было выбрать лучший, который будет способен обеспечить эффективную связь со всеми подключаемыми дополнительными модулями.
На этом же этапе подбирается стек необходимых технологий и инструментов.
Разработка программного обеспечения
- дополнительно внедренных фич;
- нехватки бюджета;
- несоблюдени я сроков;
- неопытности команды;
- излишней требовательности заказчика;
- и т. д.
Жизненный цикл разработки ПО: прохождение различных тестов
Если продукт дошел до этой стадии, то это уже успех. Однако это тоже очень важный этап, так как именно он отвечает за то, насколько качественной была разработка и насколько качественным «выйдет» программное обеспечение.
Тестирование бывает разных видов: от простого автоматизированного и до сложного ручного. Цель любого тестирования — найти возможные ошибки в программе, которые нужно исправить перед релизом ПО. Важно, чтобы продукт вышел «в руки» с минимальным количеством багов, поэтому тестированию уделяется очень много внимания.
Ввод в эксплуатацию и поддержка ПО
- поэтапным, когда ПО выпускают в ограниченный круг пользователей;
- масштабным, когда ПО доступно для всех и активно рекламируется.
- Как работает?
- Довольны ли пользователи?
- Требуются ли улучшения?
- и т. д.
Заключение
Жизненный цикл программного обеспечения одинаковый абсолютно для всех IT-проектов — от этого никуда не деться. Единственное — в зависимости от выбранных моделей разработки, больше или меньше внимания будет уделяться тем или иным стадиям самого цикла.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Источник: codernet.ru
Жизненный цикл ПО
Тестирование — это составная часть жизненного цикла любого продукта, один из ее элементов. А из чего состоит жизненный цикл программного обеспечения? С чего он начинается и заканчивается ли вообще? Давайте разбираться.
Жизненный цикл программного обеспечения включает в себя все этапы его развития: от возникновения потребности в нем до прекращения его использования.
Можно выделить несколько фаз существования программного изделия в течение его жизненного цикла. Нет каких-то общепринятых названий фаз. Да и число их меняется от источника к источнику. Однако, эти источники и не сильно противоречат друг другу.
Знать жизненный цикл ПО необходимо, чтобы понять, какое место занимает в нем тестирование. Ну и конечно это знание помогает правильно организовать разработку самого ПО.
Идея
Все начинается с идеи. Предположим, что человек занимается вязанием для продажи. Однажды он просыпается и понимает, что ему нужен интернет-магазин. Но сейчас у него ничего нет, кроме его собственной идеи.
Понятно, что с помощью только одной идеи проект не создать. В первую очередь, нужна команда, которая сможет сделать интернет магазин. И, как минимум, необходимо описание того, как будет выглядеть интернет-магазин, какая у него будет функциональность, сколько страниц и так далее. Так мы переходим к следующей стадии.
Анализ и разработка требований
Цель этой стадии – определение детальных требований к системе, то есть к нашему интернет-магазину.
На этой стадии в обсуждениях могут участвовать тестировщики, вносить свои пожелания и корректировать процесс. Кроме этого, необходимо убедиться в том, что все участники правильно поняли поставленные задачи и то, как именно каждое требование будет реализовано на практике.
Таким образом, этот этап предполагает сбор требований к разрабатываемому программному обеспечению, их систематизацию, документирование, анализ, а также выявление и разрешение противоречий.
Дизайн и Архитектура (Проектирование)
Тут начинается обсуждение, как будет выглядеть проект.
Разнообразные технические вопросы, возникающие в процессе проектирования, обсуждаются со всеми заинтересованными сторонами. Определяются технологии, которые будут использоваться в проекте, загрузка команды, ограничения, временные рамки и бюджет. В соответствии с уточненными требованиями выбираются наиболее подходящие проектные решения.
Создается прототип проекта и примерный дизайн сайта.
Разработка и программирование
После того как требования и дизайн продукта утверждены, переходим к разработке.
Здесь программисты пишут код программы в соответствии с ранее определенными требованиями. Системные администраторы настраивают программное окружение, front-end программисты разрабатывают пользовательский интерфейс программы и логику ее взаимодействия с сервером.
Другие команды также начинают свою работу: рисуется дизайн сайта, копирайтеры пишут нужный текст, происходит наполнение сайта товарами.
Тестирование
В фазе тестирования обнаруживаются пропущенные при разработке баги. При обнаружении дефекта, тестировщик составляет отчет об ошибке, который передается разработчикам. Последние его исправляют, после чего тестирование повторяется.
Тестирование повторяется до тех пор, пока не будут достигнуты критерии его окончания.
Что такое критерии окончания? Это грубо говоря определенная черта в проверках, которая скажет нам, что хватит тестировать. Они необходимо, чтобы четко понимать критерии качества продукта, но об этом мы детально поговорим в дальнейшем.
Внедрение и сопровождение
Когда сайт протестирован и в нем больше не осталось серьезных дефектов, приходит время релиза и передачи его конечным пользователям.
После выпуска новой версии программы в работу включается отдел технической поддержки, который обеспечивает обратную связь с пользователями, их консультирование и поддержку.
В случае обнаружения пользователями тех или иных пост-релизных багов, информация о них передается в виде отчетов об ошибках команде разработки.
Кроме того, команда технической поддержки помогает собирать и систематизировать различные метрики – показатели работы программы в реальных условиях.
Закрытие
К сожалению все имеет свойство заканчиваться и продукты в этом плане не исключение. Завершающий этап говорит нам о том, что продукт достиг всех поставленных целей и больше не нуждается в разработке, а следовательно должен быть закрыт.
Жизненный цикл программного обеспечения (также называемый циклом разработки) – это условная схема, включающая отдельные этапы, которые представляют стадии процесса создания ПО. При этом на каждом этапе выполняются разные действия.
Цикл разработки предлагает шаблон, использование которого облегчает проектирование, создание и выпуск качественного программного обеспечения. Это методология, определяющая процессы и средства, необходимые для успешного завершения проекта.
Хотя реализация принципов построения модели жизненного цикла для разных компаний может существенно отличаться, существуют стандарты, такие как ISO/IEC 12207, определяющие принятые практики разработки и сопровождения программного обеспечения.
Цель использования модели жизненного цикла – создать эффективный, экономически выгодный и качественный программный продукт.
Источник: sedtest-school.ru
Что такое SDLC? Этапы, методология и процессы жизненного цикла программного обеспечения
Цитируя автора книги Managing Information Technology Projects Джеймса Тейлора, «жизненный цикл проекта охватывает всю деятельность проекта». Задачей же разработки ПО является выполнение требований продукта. Если вы хотите научиться создавать и выпускать высококачественное ПО, вам придется следовать плану. Со слов Тейлора, вашей целью должен стать всесторонний анализ деятельности проекта и контроля каждого этапа его разработки. Вот только с чего именно начать?
Ответить можно так: направить ваш рабочий процесс в верном направлении поможет подходящий фреймворк. В наши дни довольно сильным и популярным фреймворком является SDLC – жизненный цикл программного обеспечения.
Принципы работы SDLC и почему им пользуются
На диаграмме ниже можно ознакомиться с шестью основными этапами SDLC.
В целом, SDLC это такой замкнутый цикл, в котором каждый этап влияет на действия в последующих и дает перспективные указания на будущее. Для получения ответов на конкретные вопросы и обеспечения согласованности вашего процесса разработки все шесть этапов стараются эффективно и последовательно друг на друга влиять.
Я постараюсь абстрагироваться от тонкостей и предоставить общие примеры, подходящие для студентов и разработчиков ПО. Например, если вы по аналогии с Zoomshift пробуете создать приложение, рассчитанное на работников с почасовой оплатой, или приложение для учета времени, начать вам нужно будет с этапа анализа требований.
На этом самом основном уровне вы сможете понять каковы должны быть требования к работникам в вопросах учета времени и труда, для чего полезно будет опросить как самих работников, так и их руководящих менеджеров. Так же для большего понимания проблем текущих приложений в области вы можете протестировать ваши решения на рынке, а создание диаграмм, графиков и в целом ведение записей поможет вам более глубоко понимать количественную и качественную обратную связь. Только после осознания этих критических особенностей вы будете готовы перейти к следующему этапу SDLC – планированию.
Фаза анализа требований может оказаться очень утомительной, но проходя через эти шаги, вы добиваетесь множества результатов: снижаете время выхода продукта на рынок, обеспечиваете большую его производительность, экономите бюджет и повышаете вероятность вхождения продукта на рынок.
Мыслите за пределами обычного приложения по отслеживанию времени — думайте о том, что вы хотите создать, чем вы хотите заниматься, а затем определите требования для решения связанных с этим проблем. Это и будет вашим началом.
Этапы SDLC и лучшие практики и методологии
В ходе разработки перед переходом от текущего этапа к следующему необходимо выполнить каждый его шаг, для чего их следует лучше понимать. В этом отношении первые три этапа стараются дать ответы на проверочные вопросы, а последние три оптимизированы для достижения фактических результатов.
- Анализ требований отвечает на вопрос «Какие проблемы требуют решений?»
- Планирование отвечает на вопрос «Что мы хотим сделать?»
- Проектирование и дизайн отвечает на вопрос «Как мы добьемся наших целей?»
- Разработка ПО регулирует процесс создания продукта.
- Тестирование регулирует обеспечение качественной работы продукта.
- Развертывание регулирует использование финального продукта.
Давайте детальнее рассмотрим каждый этап и разберем проверочные вопросы и результаты, некоторые из которых вы можете захотеть оптимизировать под вашу конкретную ситуацию.
Этап #1: Анализ требований
На этом этапе SDLC вам необходимо получить обратную связь и поддержку от соответствующих внутренних и внешних заинтересованных сторон. Вспомните мой недавний пример с разработкой приложения по учету времени: вам нужно будет широко задуматься о том, кто станут вашими потенциальными пользователями. Некоторые идеи будут включать ваших клиентов, дизайнеров, вашего начальника или других технических специалистов команды. В целом вы хотите ответить на следующий вопрос: «Какие проблемы требуют решений?» Быть внимательным и делать заметки будет очень полезно на этом этапе.
Когда полученные ответы вас удовлетворят, вы сможете перейти к следующей фазе.
Этап #2: Планирование
На этом этапе вы ищете ответ на следующий вопрос: «Что вы хотите сделать?» Этот вопрос может вдохновить вас на понимание юнит-экономики вашего плана (затраты и выгоды), факторов снижения рисков и ожидаемых стоимостей. По аналогии с планированием отпуска, вам нужно будет разложить ваши вещи и подумать о том, что следует взять с собой.
Я много читал об истории Инстаграма, чей этап планирования занял невероятно много времени. Это совпало с бурным ростом социальных сетей, поэтому взаимодействие пользователей с продуктом во многом все еще было неизвестно. Разработчики знали, что сильный первичный опыт (съемка, редактирование и обмен фотографиями) обеспечит рост, успех и высокую конверсию, а корректное планирование упростит проектирование, поэтому планировали соответствующе и тратили на дизайн много времени. Они всегда смотрели на шаг вперед и думали о будущем социальных сетей и электронной коммерции.
Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода к третьему этапу.
Этап #3: Проектирование и дизайн
К этому этапу вы уже должны знать требования вашего продукта и в целом понимать чего вы вообще хотите, и прежде чем приступить к написанию кода, этого понимания должно быть достаточно для ответа на следующий вопрос: «Как мы добьемся наших целей?» Иначе говоря, вам необходимо понять, что именно вы оптимизируете и проектировать соответствующе.
Допустим, вы хотите создать безопасное, высокопроизводительное, эффективное и выдерживающее нагрузки приложение. Какой из этих четырех принципов наиболее для вас наиболее важен? Почему? Согласны ли с этим заинтересованные стороны из первого этапа? Важно обеспечить одобрение всех участников.
После фазы дизайна вы наконец-то сможете засесть за клавиатуры, и внесение изменений в отношении времени и потраченных ресурсов будет неуклонно расти, а также буду постепенно накапливаться всевозможные малые факторы. В этой фазе для принятия окончательных решений по вопросам дизайна я рекомендую учитывать несколько основных его элементов: операционное превосходство, безопасность, надежность, эффективность производительности, и оптимизация затрат.
Этап #4: Разработка ПО
На этапе разработки вы стремитесь не столько отвечать на вопросы, сколько произвести результаты, или, говоря точнее, вам необходимо склоняться к действиям и создать прототип или систему, испытать которую смогут другие. На этом этапе ваша задача – заручиться доверием заинтересованных сторон через воплощение образа мышления разработчика. Для соответствия результата ожиданиям критично при начале разработки следовать первым трем этапам.
Доставайте ваш компьютер, убедитесь, что окружение способствует рабочей атмосфере, хватайте ваш горячий кофе – и приступайте к делу.
Этап #5: Тестирование
Сотрудники в футболках с надписями вида «Разрабатывать круто, тестировать не очень» были для меня привычным зрелищем, но вы должны понимать, что не получится создать финальную версию продукта, пока вы на нем собаку не съедите. По завершению этого этапа вы должны будете в состоянии обеспечить рабочее состояние продукта. Отслеживайте ошибки и неточности, выслушивайте чужие точки зрения, и глубоко погружайтесь в вопрос с целью поиска тормозящих выход финального продукта ошибок. Вам просто необходимо обеспечить прочную основу.
Этап #6: Развертывание
Возьмите ваш продукт и пользуйтесь им. Предложите заинтересованным сторонам из первого этапа пользоваться вашим продуктом в естественных условиях, начните отслеживать вовлеченность в продажи. Снова и снова прислушивайтесь к пользователям, ведь благодаря обратной связи через опросы и рекомендации вы сможете вернуться к первой фазе и начать собирать новые требования. И не забудьте отпраздновать релиз.
Объединяя все вместе: подход SDLC
Фреймворк SDLC существует для помощи в сокращении времени вывода продукта на рынок, обеспечении более качественной производительности, экономии бюджета и повышения потенциальной пользы вашего продукта для заинтересованных сторон, о которых вы заботитесь. Особенно хорошо SDLC помогает при разработке ПО, поскольку он заставляет вас трудиться в строгих рамках. Другими словами, для обеспечения корректных действий в корректное время и по корректным причинам SDLC заставит вас следовать каждому необходимому шагу. Думайте о SDLC как о плане по достижению успеха: слепое ему следование ничего вам не гарантирует, но повышает вероятность что вы останетесь довольны результатами.
Разработка ПО, как все мы с вами знаем, это тема обширная, и она может затрагивать вопросы от инструментов веб-дизайна и онлайн форм до более надежного машинного обучения или систем бэкенда. Пишете ли вы код в браузере или занимаетесь более надежной разработкой, план действий вам необходим.
Разработка ПО может быть трудным, и в то же время полезным занятием.
SDLC это план по ведению технических работ, но если смотреть шире, то можно воспринимать его как руководство по жизни. Применять SDLC можно к множеству тем, например, создание контента в SaaS модели ведется по циклу SDLC. Перед написанием контента автор сначала определяет требования, планирует, что именно он будет писать, и лишь затем фактически прикладывает перо к бумаге. Также SDLC отлично подходит для технологических предпринимателей.
Мой друг хотел основать лучшее рекламное агентство для Facebook и обратился ко мне и другим специалистам за помощью. Несмотря на его большие амбиции, я посоветовал ему воспользоваться фреймворком SDLC чтобы сначала провести анализ требований. Я спросил его: «Какие проблемы ты хочешь решать? Чего хотят твои пользователи? И самое главное, как эта платформа поможет тебе достичь твоих целей?»
Сформулировав эти вопросы вокруг SDLC, он смог лучше отточить свой финальный продукт и предоставить нужные инструменты правильным пользователям. Он сузил свой кругозор до более строгого определения его проблемной области и смог выделить ресурсы на планирование еще до того как он начал делать что-либо еще.
Затем он перешел к созданию самого лучшего сервиса по росту на Instagram, но его интересы постоянно развиваются, и сейчас уже есть программы-планировщики деятельности в социальных сетях в любом масштабе. И в итоге ему придется вернуться к основам: анализу требований.
Принятие пользователями его технологий доказывает, что при правильном применении SDLC можно достичь основательных технологических и финансовых результатов. Однако, как и при развитии бизнеса, разработка ПО никогда не заканчивается.
Следовательно, цикл продолжается.
Вне зависимости от того что вы создаете, компанию ли, инструмент, сложную программу либо полностью новый продукт, чтобы обеспечить качество и сосредоточиться на пользователях, хорошим решением будет взять на вооружение SDLC.
Фраза «Создавать круто» должна стать вашей путеводной звездой, а SDLC – инструментом и помощником.
Источник: habr.com