Разработка ПО и стадии жизненного цикла программного обеспечения
При этом важно отметить, что существует множество моделей жизненного цикла, например:
Любая модель регулирует лишь реализацию стадий жизненного цикла, но не сам жизненный цикл, который в принципе остается неизменным.
Жизненный цикл программного обеспечения
Итак, жизненный цикл программного обеспечения — это 6 основных стадий, через которые проходит любая разработка ПО:
Сбор и анализ требований к программному продукту.
Разработка документации для всех требований к продукту.
Разработка дизайна продукта.
Разработка программного обеспечения.
Прохождение различных тестов.
Ввод в эксплуатацию и поддержка ПО.
Сбор и анализ требований к программному продукту
Данная стадия является одной из самых основных, потому что именно она формирует дальнейший подход к разработке ПО. Все собранные на этой стадии сведения определяют:
каким должен получиться продукт «на выходе», отталкиваясь от его качества;
требования к разработчикам;
потенциальный бюджет разработки;
отношения между заказчиком и разработчиком;
В общем, данная стадия — это фундамент всех дальнейших работ.
Разработка документации для всех требований к продукту
Первую стадию прошли? Отлично! Но нужно все задокументировать, чтобы в дальнейшем не возникало не нужных проблем. Именно на этом этапе все требования к продукту и к команде разработчиков прописываются на бумаге и утверждаются с обеих сторон.
подписываются договор ы ;
прописывается план и график работ.
Разработка дизайна продукта
Под этой стадией понимают разработку внутренней архитектуры продукта, а не внешний дизайн. Важно, чтобы архитектура ПО способствовала реализации всего функционала, возложенного на сам программный продукт. Поэтому всегда предлагают несколько архитектурных вариантов, чтобы можно было выбрать лучший, который будет способен обеспечить эффективную связь со всеми подключаемыми дополнительными модулями.
На этом же этапе подбирается стек необходимых технологий и инструментов.
Разработка программного обеспечения
Требования прописаны, стек технологий выбран, что еще остается? Правильно, ко д инг! Это одна из самых «длинных» стадий жизненного цикла программного обеспечения, так как именно на этом этапе происходит реализация ПО при помощи кода.
Все фичи, модули, функционал, интерфейс и т. д. разрабатываются именно на этой стадии. Результатом конца это го этапа является готовый работающий программный продукт.
Эта стадия очень сильно отражает качество предыдущих стадий. Все ли было оговорено? Все ли задокументировано? Все ли идет четко по плану?
Именно на этом этапе могут возникать конфликты между заказчиком и разработчиком из-за:
дополнительно внедренных фич;
несоблюдени я сроков;
излишней требовательности заказчика;
Жизненный цикл разработки ПО: прохождение различных тестов
Если продукт дошел до этой стадии, то это уже успех. Однако это тоже очень важный этап, так как именно он отвечает за то, насколько качественной была разработка и насколько качественным «выйдет» программное обеспечение.
Тестирование бывает разных видов: от простого автоматизированного и до сложного ручного. Цель любого тестирования — найти возможные ошибки в программе, которые нужно исправить перед релизом ПО. Важно, чтобы продукт вышел «в руки» с минимальным количеством багов, поэтому тестированию уделяется очень много внимания.
Ввод в эксплуатацию и поддержка ПО
Если продукт разработан, прошел тестирование, если исправлены ошибки, то он выходит на последнюю стадию — релиз.
Релиз может быть разным:
поэтапным, когда ПО выпускают в ограниченный круг пользователей;
масштабным, когда ПО доступно для всех и активно рекламируется.
Довольны ли пользователи?
Требуются ли улучшения?
Обычно после релиза ПО в работу подключаются команды техподдержки, которые помогают пользователям с вопросами эксплуатации и следят за стабильной работы своего продукта.
Заключение
Жизненный цикл программного обеспечения одинаковый абсолютно для всех IT-проектов — от этого никуда не деться. Единственное — в зависимости от выбранных моделей разработки, больше или меньше внимания будет уделяться тем или иным стадиям самого цикла.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Что такое Жизненный Цикл Разработки ПО и какие проблемы возникают на каждом этапе SDLC?
Жизненный цикл разработки ПО (англ. SDLC – Software development lifecycle) – это серия из шести фаз, через которые проходит любая программная система.
Абсолютно любое ПО проходит через 6 основных шагов, начиная от простой идеи и заканчивая использованием её конечным пользователем.
Но как это выглядит изнутри? С какими сложностями сталкивается команда разработчиков и как их решает на каждой фазе Жизненного Цикла ПО? Об этом расскажет Павел Гапонов, Project Manager компании-разработчика SolveIt.
Типичный жизненный цикл разработки состоит из следующих фаз:
Это, пожалуй самый ответственный и важный из всех шагов к созданию успешной программной системы. Вся собранная информация используется для планирования базового проектного подхода.
Дополнительно идет планирование требований по обеспечению качества и выявления различных рисков, связанных с проектом. Результатом анализа является определение различных технических подходов, которые можно использовать для успешной реализации проекта с минимальными рисками. Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода ко второму этапу.
Проблема: Не соответствующие ожидания и часто изменяющиеся требования: заказчик и команда не понимают, какую реально пользу принесёт продукт.
Решение: Определить скоп работ, согласовать четкий, краткий документ с требованиями, создать прототипы (макеты) для подтверждения и уточнения окончательных требований.
Как только базовый анализ требований будет выполнен, следующим шагом будет четкое определение и документирование требований к продукту, утверждение со стороны клиента. Если одной из целей первого этапа является понимание и анализ требований, то на этом этапе все цели должны быть прописаны, это защита обеих сторон.
Важно четко определить и прописать, что требуется выполнить, это делается с помощью SRS (Software Requirement Specification). Документ содержит все требования к продукту, которые должны быть спроектированы и разработаны в течение жизненного цикла проекта.
Проблема: Большой многостраничный список требований
Решение: Выяснить высокоуровневые требования и, в ходе разработки и коммуникации с заказчиком, дописывать ТЗ. То есть разработка идет параллельно с Техническим заданием, а в процессе корректируется план.
В SolveIt мы всегда стараемся быть гибкими и подстраиваться под клиента. Работающий продукт важнее исчерпывающей документации.
SRS это ориентир для разработчиков, чтобы предложить лучшую архитектуру для продукта. Обычно предлагается несколько подходов к проектированию архитектуры продукта. Все предложенные подходы документируются в спецификации DDS (Design Document Specification) и выбирается наилучший подход к проектированию. Данный подход очень четко определяет все архитектурные модули продукта, а также его связь с внешними и сторонними модулями.
Проблема: Выбрали неправильную архитектуру.
Решение: Наличие в команде разработчиков опытных лидов, которые смогли бы предложить подходящую архитектуру, на основе своего успешного опыта в схожих проектах.
Здесь начинается разработка и сборка продукта. Весь программный код, новые модули и фичи разрабатываются на основании DDS. Чем лучше написана эта документация, тем быстрее будет идти имплементация. На этом этапе подключается команда разработчиков. Написанный код должен покрываться Unit-тестами, а взаимодействие новых фич с другими модулями тестироваться с помощью интеграционных тестов. Эти активности выполняются именно командой разработчиков, а не QA специалистами.
Проблема №1: Слабая коммуникация между командой
Разработчик не интересуется прогрессом проекта, проблемами коллег.
Решение: Daily meetings, 100% вовлеченность, Скрам доска (интерактивность).
Проблема №2: Невыполнимые сроки
Заказчик хочет, чтобы его продукт был готов в ближайшее время. Менеджер проекта пытается объяснить клиенту к чему приведет такая спешка, но этого не достаточно. Клиент ставит невыполнимые дедлайны и не слушает возражения менеджера проекта. В результате, команда разработчиков сдается и пробует закрыть задачи в слишком короткие сроки. Как следствие – критические баги из-за спешки: команда не успевает, качество продукта снижается, клиент не доволен и решает, что виновата команда.
Решение: Менеджер проекта должен стоять на своём и аргументировать дедлайны. Клиент должен понять, что если команда разработчиков будет торопиться, то не реализует часть функционала. Если всё же такой срок реализации критичен для клиента, мы стараемся выявить какие задачи находятся у заказчика в приоритете.
Проблема №3: Добавление не оговоренных фич
Решение: Менеджер проекта должен объяснить клиенту, к чему приведет добавление новых фич в проект, отстаивать свою позицию и держаться SRS. Поэтому так важна вторая фаза Жизненного цикла разработки ПО.
Именно тестирование, в основном, затрагивает все этапы жизненного цикла. Дефекты продукта регистрируются, отслеживаются, исправляются и повторно тестируются. Это происходит до тех пор, пока продукт не достигнет стандартов качества, которые прописаны в SRS. На данном этапе в процесс разработки подключается команда мануальных тестировщиков или автоматизаторы.
Проблема: Тратится слишком много времени на поиск причин багов. Попытки найти и исправить дефекты после завершения разработки – сложный процесс, который может привести к большому количеству исправлений.
Решение: Проводить тестирование параллельно задачам, сразу же по их завершению.
Как только продукт протестирован, он выходит в релиз. Иногда внедрение происходит поэтапно, в соответствии с бизнес-стратегией. Продукт сначала может быть выпущен в ограниченном сегменте и протестирован в реальной бизнес-среде, это UAT-тестирование (User Acceptance Testing). Затем, основываясь на отзывах, продукт может быть выпущен как есть, или с предлагаемыми улучшениями. После того, как продукт выпущен на рынок его обслуживание выполняется для существующей клиентской базы, и на этом этапе подключаются Support-команды.
Проблема №1: Отсутствие обратной связи, реальных отзывов потенциальных пользователей продукта.
Решение: Не ждать конца разработки, а как можно скорее запускать продукт, чтобы получить отзывы от реальных пользователей и на основе их предпочтений приоритезировать дальнейший функционал.
Проблема №2: Слабая инфраструктура проекта на стороне клиента.
Часть заказчиков предпочитают размещать сервера приложений не на Azure, AWS, Google и т.д, а в своей внутренней сети. Команда не может гарантировать стабильную работу, из-за сбоев, которые происходят на стороне клиента.
Решение: Предупредить клиента, о возможных проблемах, предложить решения для их устранения.
Если вам нужен качественный продукт, свяжитесь с нами и мы сделаем оценку вашего проекта!
Жизненный цикл разработки ПО: основные этапы и модели
Чтобы разработать программное обеспечение, нужно использовать специальный алгоритм. Его называют SDLC (Software Life Cycle Model), или жизненный цикл ПО. Это своеобразная основа, которая делает процесс разработки последовательным и упрощает техническую поддержку масштабных IT-проектов. В статье расскажем, что такое SDLC, перечислим его основные этапы и модели.
Что такое SDLC
SDLC – это алгоритм создания IT-продукта, который состоит из 6 этапов и охватывает период с момента принятия решения о его разработке и заканчивается, когда ПО перестают использовать. Каждый этап опирается на результат предыдущего и дает пул необходимых указаний для выполнения последующего.
Его функции – регламентирование и формализация процесса разработки. Это важно при командной работе, когда задействуют десятки специалистов.
Модели жизненного цикла программного обеспечения
Есть 5 моделей жизненного цикла программного обеспечения. Чаще используют каскадную, инкрементную и спиральную. V-образная и итеративная пользуются меньшим спросом в силу своей «неуниверсальности».
Каскадная
Это цикл последовательно сменяющих друг друга уровней этапов, идущих в определенной последовательности, которую нельзя менять. Каскадная модель позволяет строить относительно простые ПО, четкий список требований к которым можно сформулировать изначально.
Например, такая модель подойдет, если нужно создать усовершенствованную версию проекта или перенести готовый продукт на новую платформу.
Каскадная модель жизненного цикла ПО подходит для выполнения проектов, в которых задействовано несколько крупных команд разработчиков. Линейная структура упрощает управление и формализует взаимодействие участников.
Инкрементная
Эта модель предполагает линейную последовательность действий, поэтапную обратную связь и контроль результатов. В процессе выполнения проекта создается несколько версий – инкрементов продукта.
Использование этой модели позволяет осуществлять последовательное финансирование дорогих проектов, находить дополнительные незапланированные ресурсы и внедрять продукт поэтапно, предлагая пользователям не готовую модель с массой неочевидных недостатков, а нечто вроде тестовых версий, которые можно постепенно усовершенствовать.
Инкрементную модель используют для разработки многокомпонентных систем. Чтобы ее реализовать, заказчик должен четко понимать, как должен выглядеть желаемый результат.
Спиральная
Модель объединяет в себе два процесса – проектирование и поэтапное прототипирование ПО для проверки жизнеспособности сложных и нестандартных технических решений. Основная задача – уменьшить риски, которые влияют на организацию жизненного цикла.
Каждый условный «виток спирали» соответствует представлению очередной рабочей версии. Такая схема позволяет объективно оценить реальность выполнения отдельных задач и качество работы над проектом в целом, а также исключить серьезные баги и функциональные недочеты.
Спиральная модель хорошо себя зарекомендовала при разработке инновационных систем или новой серии продукта. Он подходит для долгосрочные проектов, в ходе разработки которых возникает необходимость в представлении промежуточных версий или внесение изменений и новый требований в ТЗ.
V-образная
По сути, это та же каскадная модель, только более усовершенствованная. От прототипа она отличается тем, что тестирование проводят на каждом этапе. Это позволяет свести к минимуму количество ошибок в архитектуре программного обеспечения.
Основной минус – такой же, как и у классической каскадной модели – нет права на ошибку. Если на каком-то из этапов разработчики допустили недочет, его исправление окажется очень трудоемким и дорогим.
Применение V-модели оправдывает себя при разработке надежных и точных продуктов. Например, систем видеонаблюдения.
Итеративная
Преимущество этой модели в том, что она позволяет «ориентироваться на местности» – заранее определять закрытый список требований и составлять объемное техническое задание не нужно. Выявить актуальность и полезность продукта, а также возможные ошибки можно на этапе черновика.
Например, вы хотите создать планировщик задач для бизнеса. Вы схематично составляете список пожеланий к функционалу и интерфейсу продукта и ставите разработчикам задачу создать пробную версию, чтобы посмотреть, как это будет выглядеть.
Когда пробная версия готова, вы тестируете ее самостоятельно и предлагаете попробовать ее использовать друзьям, коллегам, партнерам – тем, чье мнение для вас авторитетно.
Допустим, что версия оправдала самые смелые ожидания – планировать дела на неделю в ней действительно удобно, все пользователи подтвердили, что с помощью вашего продукта стали работать эффективнее.
Вы понимаете, что продукт стоит того, чтобы его доработать, предложить более широкой аудитории и начать на нем зарабатывать деньги. И уже на этом этапе целесообразно писать подробное ТЗ для разработчиков, чтобы они устранили выявленные баги, добавили полезные функции, адаптировали продукт к требованиям рынка.
К недостаткам итеративной модели следует отнести сложности в использовании баз данных или серверов и невозможность спрогнозировать сроки и спланировать бюджет. Непонятно, как будет выглядеть готовый продукт и когда его можно будет запустить.
Такая разновидность жизненного цикла ПО подходит для разработки крупных эксклюзивных проектов с постоянно меняющимися требованиями.
Этапы разработки жизненного цикла ПО на примере каскадной модели
Выделяют 6 этапов реализации каскадной модели жизненного цикла ПО. Это основные шаги, которые применяют при планировании, разработке, тестировании и развертывании программного обеспечения.
Импровизировать и менять последовательность действий в данном алгоритме нельзя – это чревато последствиями: от неоправданного увеличения трудозатрат до серьезных сбоев в командной работе и финансовых потерь.
Согласованность и целесообразность всех действий в рамках разработки ПО обусловлена жесткой последовательностью этапов и их влиянием друг на друга.
Идея. Допустим, вы хотите открыть интернет-магазин одежды. Это и есть идея, для воплощения которой нужна команда специалистов: разработчик, дизайнер, оптимизатор, специалист по юзабилити, маркетолог, копирайтер.
Ограничиться тем, что вы соберете команду и сообщите ей, что вам нужен интернет-магазин, не получится. Сам замысел необходимо развернуть. Описать, что именно вы собираетесь продавать, для какой целевой аудитории, на какой территории; озвучить общие пожелания к дизайну, примерному количеству разделов.
Анализ и разработка требований. На этом этапе в процесс включаются тестировщики. Их основные задачи – собрать, проанализировать, систематизировать и задокументировать требования к создаваемому ПО. Тестировщики озвучивают свое видение продукта, корректируют процесс, выявляют возможные противоречия.
Если вы убеждены, что все участники команды правильно понимают задачи, и ясно представляете, как именно они будут реализовывать требования к ПО на практике (и что их точно можно реализовать), можно переходить к следующему этапу.
Проектирование. Этот этап нужен для того, чтобы ответить следующие вопросы:
После того, как будут сформулированы ответы, можно разрабатывать и предлагать конкретные проектные решения. Например, на этом этапе разрабатывается и утверждается дизайн сайта.
Чтобы сделать сайт привлекательным для пользователей и повысить конверсию, можно использовать виджеты Calltouch. Они позволят автоматизировать обработку обращений клиентов и облегчить работу менеджеров компании.
Виджеты Calltouch
Программирование и разработка. К написанию кода можно приступать не ранее, чем будут утверждены требования к ПО и его дизайн. Круг задач четко очерчен и распределен – сисадмины работают над программным окружением, фронтенд-разработчики создают пользовательский интерфейс ресурса и формируют логику его взаимодействия с сервером.
Другие члены команды тем временем доводят до логического завершения дизайн, оптимизаторы составляют технические задания на тексты, копирайтеры готовят оптимизированный контент, контент-менеджер наполняет сайт товарами.
Тестирование. Тестирование – проверка готового к запуску сайта на всевозможные баги. Тестировщики досконально изучают ресурс, выявляют ошибки и передают информацию о них разработчикам в виде подробных отчетов. После устранения ошибок тестирование выполняется снова.
Этот цикл повторяется до тех пор, пока количество багов не станет минимальным или равным нулю. У каждого ресурса есть свой порог, после которого можно прекратить его тестировать.
Основная задача этапа – удостовериться, что продукт находится полностью в рабочем состоянии, и его можно запускать в работу.
Запуск, аналитика и сопровождение. Как только вы поймете, что в ПО не осталось серьезных дефектов и оно полностью готово к запуску, пришла пора официально выпустить готовый качественный программный продукт.
На данном этапе в процесс включается специалист по технической поддержке, который будет давать обратную связь пользователям, оказывать консультации, исправлять недочеты в соответствии с их пожеланиями и замечаниями.
Пользователи могут столкнуться с пострелизными багами и обратиться в техподдержку в нерабочее время. Чтобы не упустить ни одного обращения и показать клиентоориентированность компании, подключите обратный звонок Calltouch. Клиент оставит заявку, а система свяжет с ним специалиста, как только начнется рабочий день.
Виджет обратного звонка для сайта
Другая важная функция отдела технической поддержки – сбор, анализ и систематизация различных метрик – показателей того, как работает продукт в реальных условиях. Это лучший способ понять, насколько он соответствует ожиданиям.
Закрытие. Это завершающий этап жизненного цикла ПО. Он наступает, когда вы понимаете, что достигли при помощи вашего продукта всех поставленных целей и готовы его закрыть и перейти на новый уровень.
Коротко о главном
При выборе модели жизненного цикла ПО ориентируйтесь на особенности продукта, который вы хотите получить, и потребности целевой аудитории. Для реализации сложных многоступенчатых систем, простых продуктов и их новых версий подходят разные модели SDLC. Грамотно выбрав вид алгоритма, вы запустите действительно успешный продукт, который будет востребован у пользователей, и потратите разумное количество времени и денег на воплощение идеи.
Жизненный цикл программного обеспечения
Содержание
Стандарты жизненного цикла ПО
Стандарт ГОСТ 34.601-90
Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:
Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.
Данный стандарт не вполне подходит для проведения разработок в настоящее время: многие процессы отражены недостаточно, а некоторые положения устарели.
Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207)
Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes».
Данный стандарт, используя устоявшуюся терминологию, устанавливает общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии. Стандарт определяет процессы, виды деятельности и задачи, которые используются при приобретении программного продукта или услуги, а также при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов.
Процессы жизненного цикла ПО
Стандарт группирует различные виды деятельности, которые могут выполняться в течение жизненного цикла программных систем, в семь групп процессов. Каждый из процессов жизненного цикла в пределах этих групп описывается в терминах цели и желаемых выходов, списков действий и задач, которые необходимо выполнять для достижения этих результатов.
Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:
Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:
Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями
Модель жизненного цикла ПО — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ ПО включает в себя:
Стадия — часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.
На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.
Модели жизненного цикла ПО
Водопадная (каскадная, последовательная) модель
Водопадная модель жизненного цикла (англ. waterfall model ) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью:
Итерационная модель
Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).
Спиральная модель
Спиральная модель (англ. spiral model ) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются:
Отличительной особенностью спиральной модели является специальное внимание, уделяемое рискам, влияющим на организацию жизненного цикла, и контрольным точкам. Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:
В сегодняшней спиральной модели определён следующий общий набор контрольных точек [5] :