Стадии жизненного цикла программного обеспечения: Жизненный цикл программного продукта — it-black.ru

Жизненный цикл программного продукта — it-black.ru

Жизненный цикл программного продукта — it-black.ru Перейти к содержимому

Любой разработчик программного продукта должен хорошо понимать и разбираться в этапах жизненного цикла программного обеспечения. В этой статье Вы познакомитесь с этой темой подробнее.

Жизненный цикл программного продукта представляет собой непрерывный процесс, начинающийся с момента принятия решения о создании программного обеспечения и заканчивающийся в момент полного изъятия его из эксплуатации.

Этапы жизненного цикла программного продукта

1. Анализ требований

Данная стадия является одной из важнейших, поскольку определяет успех всего проекта. На данном этапе формируются цели и задачи проекта, устанавливается область применения программного обеспечения (ПО) и определяются граничные условия, выделяются базовые сущности и взаимосвязи между ними.

Определяются сроки и стоимость разработки ПО, формируется и подписывается техническое задание на разработку ПО.

2. Стадия проектирования

Проектирование включает в себя определение архитектуры программной системы, её функций, внешних условий функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам. Проектирование системы проводится на основе результатов формирования требований.

Разрабатывается функциональная спецификация ПО, выбирается архитектура системы, определяется наиболее подходящая СУБД, проектируются структуры хранения данных, оговариваются требования к аппаратному обеспечению, определяется набор организационных мероприятий, которые необходимы для внедрения ПО, а также перечень документов регламентирующих его использование.

3. Кодирование (программирование)

На данной стадии строятся прототипы как целой программной системы, так и её частей, осуществляется физическая реализация структур данных, разрабатывается программные коды, выполняется отладочное тестирование, создается техническая документация.

В результате этапа кодирования появляется рабочая версия продукта.

4. Тестирование и отладка

Тестирование ПО тесно связано с этапами проектирования и реализации. В систему встраиваются специальные механизмы, которые дают возможность производить тестирование программного обеспечения на соответствие требований к нему, проверку оформления и наличие необходимого пакета документации.

Результатом тестирования является устранение всех недостатков программного продукта и заключение о её качестве.

5. Эксплуатация и сопровождение

Ввод в эксплуатацию ПО предусматривают установку программной системы, обучение пользователей, документирование. Поддержка функционирования ПО должна осуществляться группой технической поддержки разработчика.

Сопровождение – это процесс адаптации поставляемого ПО к новым условиям, внесения изменений в ПО и соответствующую документацию, вызванных возникшими проблемами или потребностями в модификации при сохранении неизменными его основных функций.

Вывод из эксплуатации программного обеспечения осуществляется в результате его морального, прихода на смену более совершенных продуктов или по иным объективным или субъективным причинам.

Стандарты процессов жизненного цикла программного продукта

1. Международный стандарт ISO/IEC 1227: 1995-08-01, первая редакция которого подготовлена в 1995 г. Объединённым комитетом ISO/IEC JTC1 »Информационные технологии, … проектирование программного обеспечения».

2. ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология (ИТ). Системная и программная инженерия. Процессы жизненного цикла программных средств.

3. Отечественный комплекс стандарта ГОСТ 34 (ГОСТ 34.601-90, ГОСТ 34.602-89, …).

4. Методические указания РД 50-34.698-90.

5. Методика Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ.

Facebook

Twitter

• Виктор Черемных
• 16 сентября, 2018
• No Comments

Группа в VK

Обнаружили опечатку?

Сообщите нам об этом, выделите текст с ошибкой и нажмите Ctrl+Enter, будем очень признательны!

Свежие статьи

Облако меток

Похожие статьи

Решение проблемы в оффлайн браузере Zeal — Content rendering error

В этом видео мы решаем проблему загрузки контента в оффлайн браузере Zeal.  

Установка и обзор оффлайн браузера документации по программированию

В этом видео вы научитесь устанавливать оффлайн браузер Zeal для работы с документацией по программированию.  

Зачем программисту изучать алгоритмы?

За всю историю компьютерных наук сложилось понимание, какие алгоритмы и структуры данных (способы их хранения) нужны для решения практических задач — так называемый джентльменский набор,

Что такое API?

API — это аббревиатура от английского Application Programming Interface, интерфейс программирования приложения. Говоря по-простому, API действует как виртуальный посредник и передает информацию из одного интерфейса,

Instagram Vk Youtube Telegram Odnoklassniki

Полезно знать

Рубрики

Авторы

Разработка ПО и стадии жизненного цикла программного обеспечения

Жизненный цикл программного обеспечения — это ряд этапов, через которые проходит любой программный продукт от момента идеи и до момента выпуска ПО в широкое пользование. По сути, жизненный цикл разработки ПО — это и есть сам процесс разработки и развитие программного продукта.

При этом важно отметить, что существует множество моделей жизненного цикла, например:

• каскадная,

• инкрементная,

• спиральная,

• и др.

Любая модель регулирует лишь реализацию стадий жизненного цикла, но не сам жизненный цикл, который в принципе остается неизменным.

 

Жизненный цикл программного обеспечения

Итак, жизненный цикл программного обеспечения — это 6 основных стадий, через которые проходит любая разработка ПО:

1. Сбор и анализ требований к программному продукту.

2. Разработка документации для всех требований к продукту.

3. Разработка дизайна продукта.

4. Разработка программного обеспечения.

5. Прохождение различных тестов.

6. Ввод в эксплуатацию и поддержка ПО.

 

Сбор и анализ требований к программному продукту

Данная стадия является одной из самых основных, потому что именно она формирует дальнейший подход к разработке ПО. Все собранные на этой стадии сведения определяют:

• каким должен получиться продукт «на выходе», отталкиваясь от его качества;

• требования к разработчикам;

• возможные риски, связанные с разработкой и внедрением ПО;

• подход к тому, как будет реализована разработка ПО;

• потенциальный бюджет разработки;

• отношения между заказчиком и разработчиком;

• и др.

В общем, данная стадия — это фундамент всех дальнейших работ.

 

Разработка документации для всех требований к продукту

Первую стадию прошли? Отлично! Но нужно все задокументировать, чтобы в дальнейшем не возникало ненужных проблем. Именно на этом этапе все требования к продукту и к команде разработчиков прописываются на бумаге и утверждаются с обеих сторон.

С одной стороны, документация — это лишняя бюрократия. Но в некоторых случаях именно этот этап и четко задокументированные требования защищают заказчика и разработчиков от неприятных ситуаций и претензий.

На этой стадии:

 

Разработка дизайна продукта

Под этой стадией понимают разработку внутренней архитектуры продукта, а не внешний дизайн. Важно, чтобы архитектура ПО способствовала реализации всего функционала, возложенного на сам программный продукт. Поэтому всегда предлагают несколько архитектурных вариантов, чтобы можно было выбрать лучший, который будет способен обеспечить эффективную связь со всеми подключаемыми дополнительными модулями.

На этом же этапе подбирается стек необходимых технологий и инструментов.

 

Разработка программного обеспечения

Требования прописаны, стек технологий выбран, что еще остается? Правильно, кодинг! Это одна из самых «длинных» стадий жизненного цикла программного обеспечения, так как именно на этом этапе происходит реализация ПО при помощи кода.

Все фичи, модули, функционал, интерфейс и т. д. разрабатываются именно на этой стадии. Результатом конца этого этапа является готовый работающий программный продукт.

Эта стадия очень сильно отражает качество предыдущих стадий. Все ли было оговорено? Все ли задокументировано? Все ли идет четко по плану?

Именно на этом этапе могут возникать конфликты между заказчиком и разработчиком из-за:

• дополнительно внедренных фич;

• нехватки бюджета;

• несоблюдения сроков;

• неопытности команды;

• излишней требовательности заказчика;

• и т.  д.

 

Жизненный цикл разработки ПО: прохождение различных тестов

Если продукт дошел до этой стадии, то это уже успех. Однако это тоже очень важный этап, так как именно он отвечает за то, насколько качественной была разработка и насколько качественным «выйдет» программное обеспечение.

Тестирование бывает разных видов: от простого автоматизированного и до сложного ручного. Цель любого тестирования — найти возможные ошибки в программе, которые нужно исправить перед релизом ПО. Важно, чтобы продукт вышел «в руки» с минимальным количеством багов, поэтому тестированию уделяется очень много внимания.

 

Ввод в эксплуатацию и поддержка ПО

Если продукт разработан, прошел тестирование, если исправлены ошибки, то он выходит на последнюю стадию — релиз.

Релиз может быть разным:

• поэтапным, когда ПО выпускают в ограниченный круг пользователей;

• масштабным, когда ПО доступно для всех и активно рекламируется.

Неважно, как происходит релиз ПО, важно первое время за ним очень пристально наблюдать:

Обычно после релиза ПО в работу подключаются команды техподдержки, которые помогают пользователям с вопросами эксплуатации и следят за стабильной работы своего продукта.

 

Заключение

Жизненный цикл программного обеспечения одинаковый абсолютно для всех IT-проектов — от этого никуда не деться. Единственное — в зависимости от выбранных моделей разработки, больше или меньше внимания будет уделяться тем или иным стадиям самого цикла.

7 этапов руководства по жизненному циклу разработки системы

Процесс разработки программного обеспечения обычно долгий и утомительный. Но менеджеры проектов и системные аналитики могут использовать жизненные циклы разработки программного обеспечения для планирования, проектирования, разработки, тестирования и, в конечном итоге, развертывания информационных систем или программных продуктов с большей регулярностью, эффективностью и общим качеством.

‍

Что такое жизненный цикл разработки системы?

Жизненный цикл разработки системы или SDLC — это, по сути, модель управления проектом. Он определяет различные этапы, необходимые для того, чтобы довести проект от его первоначальной идеи или концепции до развертывания и последующего обслуживания.

‍

В этом руководстве мы разберем все, что вам нужно знать о жизненном цикле разработки системы, включая все его этапы. Мы также рассмотрим роли системных аналитиков и преимущества, которые может получить ваш проект при внедрении SDLC.

‍

7 стадий жизненного цикла разработки системы

Существует семь основных стадий жизненного цикла разработки современной системы. Вот краткая разбивка:

• Этап планирования
• Выполнимость или требования анализа Этап
• Этап проектирования и прототипирования
• Этап разработки программного обеспечения
• Этап тестирования программного обеспечения
• Этап внедрения и интеграции
• Этап эксплуатации и обслуживания

Теперь давайте более подробно рассмотрим каждый этап в отдельности.

‍

Этап планирования

Еще до того, как мы начнем этап планирования, лучший совет, который мы можем вам дать, — уделить время и правильно понять жизненный цикл разработки приложения.

Стадия планирования (также называемая стадией технико-экономического обоснования) — это именно то, на что это похоже: фаза, на которой разработчики будут планировать предстоящий проект.

Помогает определить проблему и область применения любых существующих систем, а также определить цели для их новых систем.

Разработав эффективный план предстоящего цикла разработки, они теоретически смогут выявить проблемы до того, как они повлияют на разработку.

И помогите получить финансирование и ресурсы, необходимые им для реализации их плана.

Возможно, наиболее важно то, что на этапе планирования устанавливается график проекта, который может иметь ключевое значение, если речь идет о разработке коммерческого продукта, который должен быть выпущен на рынок к определенному времени.

‍

Этап анализа

Этап анализа включает в себя сбор всех конкретных деталей, необходимых для новой системы, а также определение первых идей для прототипов.

Разработчики могут:

• Определять любые требования к системе прототипа
• Оценка альтернатив существующим прототипам
• Выполнение исследований и анализа для определения потребностей конечных пользователей

Кроме того, разработчики часто создают спецификацию требований к программному обеспечению или документ SRS.

Сюда входят все спецификации программного и аппаратного обеспечения, а также требования к сети для системы, которую они планируют построить. Это предотвратит перерасход средств или ресурсов при работе в одном месте с другими командами разработчиков.

‍

Этап проектирования

Этап проектирования является необходимым предшественником основного этапа разработки.

Разработчики сначала описывают детали приложения в целом, а также конкретные аспекты, такие как:

• Пользовательские интерфейсы
• Системные интерфейсы
• Сеть и сетевые требования
• Базы данных

они превратились в более логичную структуру, которую впоследствии можно реализовать на языке программирования. Будут составлены планы эксплуатации, обучения и обслуживания, чтобы разработчики знали, что им нужно делать на каждом этапе цикла в будущем.

После завершения менеджеры по разработке подготовят проектный документ, на который будут ссылаться на следующих этапах SDLC.

‍

Стадия разработки

Стадия разработки — это часть, на которой разработчики фактически пишут код и создают приложение в соответствии с более ранней проектной документацией и заданными спецификациями.

Именно здесь в игру вступают инструменты статического тестирования безопасности приложений или SAST.

Программный код продукта создается в соответствии со спецификациями проектной документации. Теоретически все предварительное планирование и наброски должны сделать фактическую фазу разработки относительно простой.

Разработчики будут следовать всем правилам кодирования, установленным организацией, и использовать различные инструменты, такие как компиляторы, отладчики и интерпретаторы.

Языки программирования могут включать основные элементы, такие как C++, PHP и другие. Разработчики выберут правильный программный код для использования на основе спецификаций и требований проекта.

‍

Этап тестирования

Создание программного обеспечения — это не конец.

Теперь его необходимо протестировать, чтобы убедиться в отсутствии ошибок и в том, что это никоим образом не повлияет на работу конечного пользователя.

На этапе тестирования разработчики тщательно проверяют свое программное обеспечение, отмечая любые ошибки или дефекты, которые необходимо отследить, исправить и позже повторно протестировать.

Важно, чтобы программное обеспечение в целом соответствовало стандартам качества, ранее определенным в документе SRS.

В зависимости от навыков разработчиков, сложности программного обеспечения и требований к конечному пользователю тестирование может быть очень коротким этапом или длиться очень долго. Взгляните на наши 10 лучших практик для проектов тестирования программного обеспечения для получения дополнительной информации.

‍

Стадия внедрения и интеграции

После тестирования общий дизайн программного обеспечения будет готов. Различные модули или конструкции будут интегрированы в первичный исходный код благодаря усилиям разработчиков, обычно путем использования обучающих сред для обнаружения дополнительных ошибок или дефектов.

Информационная система будет интегрирована в свою среду и в конечном итоге установлена. После прохождения этого этапа программное обеспечение теоретически готово к выпуску на рынок и может быть предоставлено любым конечным пользователям.

‍

Этап обслуживания

SDLC не заканчивается, когда программное обеспечение выходит на рынок. Теперь разработчики должны перейти в режим обслуживания и начать отрабатывать любые действия, необходимые для решения проблем, о которых сообщают конечные пользователи.

Кроме того, разработчики несут ответственность за внесение любых изменений, которые могут потребоваться в программном обеспечении после развертывания.

Это может включать обработку остаточных ошибок, которые не удалось исправить до запуска, или решение новых проблем, возникающих из-за пользовательских отчетов. Для больших систем могут потребоваться более длительные этапы обслуживания по сравнению с меньшими системами.

‍

Роль системного аналитика

Системный аналитик SDLC в некотором смысле является контролером всей системы. Они должны быть полностью осведомлены о системе и всех ее движущихся частях и могут помочь в управлении проектом, давая соответствующие указания.

Системный аналитик должен быть:

• Экспертом в любых технических навыках, необходимых для проекта
• Хорошим коммуникатором, чтобы помочь своей команде добиться успеха
• Хорошим планировщиком, чтобы задачи разработки могли выполняться вовремя на каждом этапе цикла разработки

Таким образом, системные аналитики должны обладать равномерным сочетанием межличностных, технических, управленческих и аналитических навыков. Это универсальные профессионалы, которые могут создать или сломать SDLC.

Их обязанности довольно разнообразны и важны для конечного успеха данного проекта. От системных аналитиков часто ожидают:

• ️Сбор фактов и информации
• Принятие командных решений о том, какие ошибки расставить по приоритетам или какие функции вырезать
• Предложить альтернативные решения
• Нарисовать спецификации, понятные как пользователям, так и программистам
• Внедрить логические системы, сохраняя при этом модульность для последующей интеграции
• Быть способным оценивать и модифицировать полученную систему в соответствии с целями проекта
• Помощь планировать требования и цели проекта путем определения и понимания требований пользователей

‍

6 Основные методологии SDLC

Хотя жизненный цикл разработки системы является моделью управления проектами в широком смысле, можно использовать еще шесть конкретных методологий для достижения конкретных результатов или обеспечения более крупного SDLC с различными атрибутами.

‍

Водопадная модель

Водопадная модель является старейшей из всех методологий SDLC. Он линейный и простой и требует, чтобы команды разработчиков полностью завершили одну фазу проекта, прежде чем переходить к следующей.

Каждый этап имеет отдельный план проекта и берет информацию из предыдущего этапа, чтобы избежать подобных проблем (если они возникнут). Тем не менее, он уязвим для ранних задержек и может привести к большим проблемам, возникающим у команд разработчиков в будущем.

‍

Итерационная модель

Итеративная модель фокусируется на повторении и повторном тестировании. Новые версии программного проекта создаются в конце каждого этапа, чтобы выявить потенциальные ошибки и позволить разработчикам постоянно улучшать конечный продукт к тому времени, когда он будет готов к выходу на рынок.

Одним из преимуществ этой модели является то, что разработчики могут создать рабочую версию проекта относительно рано в своем жизненном цикле разработки, поэтому внедрение изменений часто обходится дешевле.

‍

Спиральная модель

Спиральные модели являются гибкими по сравнению с другими методологиями. Проекты снова и снова проходят через четыре основные фазы в метафорическом спиралевидном движении.

Это выгодно для крупных проектов, поскольку команды разработчиков могут создавать очень индивидуальные продукты и учитывать любые полученные отзывы на относительно раннем этапе жизненного цикла.

‍

V-модель

V-модель (сокращение от Verification and Validation) очень похожа на водопадную модель. Фаза тестирования включена в каждую стадию разработки для выявления потенциальных ошибок и дефектов.

Это невероятно дисциплинирует и требует строгих сроков. Но в теории она освещает недостатки основной модели водопада, предотвращая выход из-под контроля более крупных ошибок.

‍

Модель Big Bang

Модель Большого взрыва невероятно гибкая и не следует строгому процессу или процедуре. Он оставляет позади даже детальное планирование. Он в основном используется для разработки общих идей, когда покупатель или клиент не уверены, чего они хотят. Разработчики просто начинают проект с деньгами и ресурсами.

Их результат может быть ближе или дальше от того, что клиент в конечном итоге понимает, что он хочет. Он в основном используется для небольших проектов и экспериментальных жизненных циклов, предназначенных для информирования других проектов в той же компании.

‍

Модель Agile

Модель Agile относительно хорошо известна, особенно в индустрии разработки программного обеспечения.

Гибкая методология отдает приоритет быстрым и непрерывным циклам выпуска, используя небольшие, но постепенные изменения между выпусками. Это приводит к большему количеству итераций и гораздо большему количеству тестов по сравнению с другими моделями.

Теоретически эта модель помогает командам решать небольшие проблемы по мере их возникновения, а не откладывать их до более поздних, более сложных этапов проекта.

‍

Преимущества SDLC

SDLC предоставляет ряд преимуществ командам разработчиков, которые правильно его реализуют.

‍

Четкое описание целей

Разработчики четко знают цели, которые им необходимо достичь, и результаты, которые они должны достичь в установленные сроки, что снижает риск потери времени и ресурсов впустую.

‍

Надлежащее тестирование перед установкой

Модели SDLC реализуют систему сдержек и противовесов, чтобы гарантировать, что все программное обеспечение тестируется перед установкой в ​​расширенном исходном коде.

‍

Очистить прогресс стадии

Разработчики не могут перейти к следующей эпохе, пока предыдущая не будет завершена и не подписана менеджером.

‍

Гибкость участников

Поскольку SDLC имеют хорошо структурированные документы для целей проекта и методологий, члены команды могут уйти и быть заменены новыми членами относительно безболезненно.

‍

Совершенство достижимо

Все этапы SDLC предназначены для обратной связи друг с другом. Таким образом, модели SDLC могут помочь проектам повторять и улучшать себя снова и снова, пока они не станут практически идеальными.

‍

Ни один участник не создает и не разрушает проект

Опять же, поскольку SDLC используют обширную документацию и руководящие документы, это командная работа, и потеря даже одного важного участника не поставит под угрозу сроки проекта.

‍

Что нужно знать о жизненном цикле разработки системы

Где используется SDLC?

Жизненные циклы разработки системы обычно используются при разработке ИТ-проектов.

Менеджеры по разработке программного обеспечения будут использовать SDLC, чтобы наметить различные этапы разработки, следить за тем, чтобы все выполняли этапы вовремя и в правильном порядке, а также чтобы проект выполнялся как можно быстрее и без ошибок.

SDLC также могут более конкретно использоваться системными аналитиками при разработке и последующем внедрении новой информационной системы.

‍

Какая модель SDLC лучше?

Во многом это зависит от целей вашей команды и потребностей в ресурсах.

Большинство групп ИТ-разработчиков используют гибкую методологию для своего SDLC. Однако другие могут предпочесть итеративные или спиральные методологии.

Все эти три метода популярны, поскольку они позволяют провести обширную итерацию и тестирование на наличие ошибок, прежде чем продукт будет интегрирован с большим исходным кодом или выпущен на рынок.

Методологии DevOps также являются популярным выбором. И если вам когда-нибудь понадобится курс повышения квалификации по DevOps, вам не о чем беспокоиться, так как наша команда CloudDefense поможет вам!

‍

Что разрабатывает SDLC?

SDLC можно использовать для разработки или проектирования программного обеспечения, систем и даже информационных систем. Его также можно использовать для разработки аппаратного обеспечения или комбинации программного и аппаратного обеспечения одновременно.

‍

Часто задаваемые вопросы

Каковы были 5 исходных фаз жизненного цикла разработки системы?

Жизненный цикл разработки систем изначально состоял из пяти этапов вместо семи. К ним относятся планирование, создание, разработка, тестирование и развертывание. Обратите внимание, что в нем не учитываются основные этапы анализа и обслуживания.

‍

Каковы 7 этапов SDLC?

Новые семь этапов SDLC включают планирование, анализ, проектирование, разработку, тестирование, внедрение и обслуживание.

‍

Что такое жизненный цикл разработки системы в ИСУ?

В более широком контексте информационных систем управления или MIS SDLC помогает менеджерам проектировать, разрабатывать, тестировать и развертывать информационные системы для достижения поставленных целей.

‍

Заключение

В конечном счете, любая команда разработчиков как в ИТ, так и в других отраслях может извлечь выгоду из реализации жизненных циклов разработки систем в своих проектах. Используйте приведенное выше руководство, чтобы определить, какую методологию вы хотите использовать в сочетании с SDLC для достижения наилучших результатов.

Понимание этапов жизненного цикла разработки программного обеспечения

Жизненный цикл разработки программного обеспечения (SDLC) — это процесс создания программного обеспечения самого высокого качества и с наименьшими затратами. Узнайте, как Harness рассматривает процесс SDLC.

В то время как технологии, методы и взгляды на создание высокопроизводительных и масштабируемых программных сервисов изменились, обязанности и действия остались прежними. Жизненный цикл разработки программного обеспечения (SDLC) — это ряд важных этапов, определенных для команд, производящих и поставляющих высококачественное программное обеспечение. В этом сообщении блога будет более подробно обсуждаться SDLC и его этапы.

Что такое жизненный цикл разработки программного обеспечения?

Жизненный цикл разработки программного обеспечения относится к этапам работы, связанной с созданием программных приложений. Каждая фаза соответствует роли или ответственности, которую участники программного обеспечения должны понимать, управлять и оптимизировать, чтобы предоставлять свои программные услуги быстро и эффективно. К таким этапам работ относятся:

• Сбор требований, 
• Дизайн ПО, 
• Разработка ПО, 
• Тестирование и интеграция,
• Развертывание,
• Эксплуатация и обслуживание.

Остановимся подробнее на каждом этапе работы.

Этапы SDLC

Сбор требований

На этом этапе работы группа выявляет, собирает и определяет текущие проблемы, требования, запросы и ожидания клиентов, связанные с программным приложением или услугой.

Некоторые действия, связанные с этапом сбора требований, могут включать в себя создание спецификаций программного обеспечения, создание подробного плана, документации, отслеживание проблем и планирование проекта или продукта, включая правильное выделение ресурсов.

Определение требований к программному обеспечению или продукту дает командам прогнозирование и контекст, необходимые для доставки и производства их программных решений.

Разработка программного обеспечения

На этом этапе проектирования команда принимает решения по проектированию программного обеспечения, касающиеся архитектуры и производителя программного решения. Это может включать создание проектной документации, руководств по кодированию и обсуждение инструментов, методов, сред выполнения или сред, которые помогут команде выполнить спецификацию требований к программному обеспечению и цели, определенные на этапе сбора требований.

Разработка программного обеспечения

На этом этапе работы команды создают программные решения на основе принятых проектных решений. Здесь команды достигают целей и результатов, установленных на этапе сбора требований к программному обеспечению, внедряя решение.

Процесс разработки может включать в себя команды людей, новые технологии и неожиданные проблемы; однако команды разработчиков обычно работают с техническими руководителями и менеджерами по продуктам или проектам, чтобы разблокировать процесс, принять решения или оказать поддержку. Этот этап работы заканчивается, когда команды упаковывают и создают свой код.

Тестирование и интеграция

На этом этапе работы программная реализация упаковывается и тестируется для обеспечения качества. Тестирование или обеспечение качества гарантирует, что реализованные решения соответствуют стандартам качества и производительности. Это может включать модульное тестирование, выполнение интеграционных и сквозных тестов, проверку/валидацию, а также отчетность или выявление ошибок или дефектов в программном решении.

Развертывание

На этом этапе работы программное обеспечение развертывается в производственной среде. Собранная, спроектированная, разработанная и протестированная работа предоставляется потребителям и пользователям программного сервиса. Этот процесс включает в себя подготовку инфраструктуры в рамках локального или облачного поставщика и определение стратегии развертывания программного обеспечения для доставки изменений клиенту.

Если вы хотите узнать больше, мы разберем стратегии развертывания и обсудим, когда и почему следует использовать каждый тип.

Эксплуатация и техническое обслуживание 

На этом этапе работы программное обеспечение приводится в действие, чтобы гарантировать отсутствие проблем или инцидентов, связанных с развертыванием. Этот этап работы может включать проверку, понимание и мониторинг параметров сети, конфигураций инфраструктуры и производительности сервисов приложений в рабочей среде. Этот процесс может включать разрешение или управление инцидентами в ходе любых проблем или изменений, вносимых с целью повлиять на клиентскую или пользовательскую базу.

Почему SDLC важен для доставки ПО?

Теперь, когда мы знаем больше о работе, связанной с каждой частью SDLC, мы можем обсудить, почему это важно и как это применимо к тому, как мы поставляем программное обеспечение сегодня. Для многих организаций проблемой является более быстрая поставка лучшего программного обеспечения. Понимание SDLC позволяет командам понять, что нужно для доставки функций или изменений кода клиентам.

Реальность для многих разработчиков заключается в том, что им приходится ждать месяцы или годы, прежде чем изменения в коде станут доступны пользователям, в сочетании с отсутствием видимости, коммуникации и совместной работы во время процесса. Организации и команды, которые имеют возможность развертывания по запросу и в режиме самообслуживания, расширяют возможности своих команд, чтобы продолжать делать свою работу наилучшим образом.

Согласно нашему отчету Continuous Delivery 2020 Insights, инженерные группы ежегодно тратят в среднем 109 000 долларов США на развертывание и доставку своих программных приложений. Усилия по внедрению в производство приводят в среднем к 25 часам инженерных работ.

SDLC дает представление об отдельных этапах работы, необходимых для создания программного обеспечения. Понимание этой работы позволяет командам избегать проблем с доставкой, создавая и контролируя систему сдержек и противовесов на ранних стадиях нашего жизненного цикла разработки и доставки.

Это также относится к учету отзывов и идей в процессе разработки программного обеспечения, чтобы постоянно приносить пользу воспроизводимым, быстрым и устойчивым образом.

Понимание SDLC также позволяет командам повысить производительность DevOps, которую можно измерить с помощью показателей DORA .

Примеры модели жизненного цикла разработки программного обеспечения

Ученые-компьютерщики, специалисты-практики в области разработки программного обеспечения и руководители всегда стремились быстрее создавать более качественное программное обеспечение. Со временем появилось несколько моделей (таких как каскадная, спиральная, Agile) для описания и представления процессов SDLC и управления уровнем сложности разработки по мере изменения спроса, инструментов, процессов и мышления.

Водопадная модель

Возможно, одной из первых моделей, используемых для представления процесса доставки программного обеспечения, является водопадная модель, разработанная в 1956 году. В этой модели цепочка линейных последовательных фаз представляет действия по доставке программного обеспечения.

Каждый этап зависит от доставки и выполнения предыдущего этапа, где каждый этап содержал набор задач. Эта модель возникла в производственной и строительной отраслях и была адаптирована для знаний или творческой работы, основанной на проектах.

Недостатком этой модели являются ее зависимости. Поскольку прогресс идет в одном направлении, остается мало места для адаптации к вновь обнаруженным ограничениям, требованиям и проблемам после принятия проектных решений и начала реализации.

Поставка всего программного обеспечения также приведет к увеличению затрат, так как изменения в требованиях повлекут за собой серьезные изменения конструкции, переработку и повторное тестирование. Эти недостатки приводят к модифицированным моделям водопада, таким как сашими (водопад с перекрывающимися фазами), водопад с подпроектами и водопад с уменьшением риска.

Итеративная и инкрементная модель

В ответ на предполагаемые проблемы с водопадной моделью такие организации, как Министерство обороны США, выпустили заявления, такие как MIL-STD-498, поощряющие «итеративную и инкрементальную разработку». Это привело к появлению термина, объединяющего как итеративный дизайн, так и пошаговые шаблоны разработки.

В этой модели программное обеспечение разрабатывается и поставляется посредством повторяющихся циклов небольших частей работы. Эта модель позволяет командам разработчиков программного обеспечения использовать знания и идеи, сделанные ранее в процессе разработки и использования программной системы. Команды на каждой итерации работ вносят необходимые изменения в дизайн и дополнительные функциональные возможности.

Проект НАСА «Меркурий» 1960-х годов является примером раннего использования модели итеративной и поэтапной разработки. Успех проекта позже привел к дальнейшему внедрению, поскольку инженеры Project Mercury перешли к другим командам и проектам.

Хотя истоки итерационной модели связаны с индустрией программного обеспечения, многие усилия по разработке аппаратного и встроенного программного обеспечения в настоящее время используют итерационные и инкрементные методы (например, такие компании, как SpaceX и Rocket Lab).

Эволюция моделей процессов

Вслед за успехом итеративных и инкрементных методов разработки программного обеспечения появились другие методы разработки программного обеспечения, позволяющие использовать больше принципов управления проектами и практики разработки.

Спиральная модель — это одна из моделей разработки, основанная на оценке риска, которая побуждает проектные группы работать на основе уникальных проектных рисков, используя один или несколько элементов других методологий реализации. В 1990-х годах манифест Agile привел к принятию и популярности модели Agile и последующих методологий Agile.

Сегодня у нас есть жизненный цикл DevOps, представляющий SDLC и наши цели по постоянному повышению ценности программного обеспечения в качестве межфункциональной команды.

То, как вы будете разрабатывать или доставлять, зависит только от вас. Важно знать, что происходит в процессе. В этом сообщении блога обсуждался жизненный цикл разработки программного обеспечения и модели SDLC, которые появились, чтобы позволить нам сегодня создавать и совместно использовать наши программные сервисы. Удачи всем, кто управляет или участвует в жизненном цикле проекта!

Расширьте свои знания об инструментах SDLC

Специалисты в предметной области, архитекторы, разработчики систем, инженеры и руководители заинтересованы в создании отличного программного обеспечения.