Самый большой этап в жизненном цикле программы

Жизненный цикл разработки ПО (System/Software Development Life Cycle, SDLC) — процесс, состоящий из конкретных этапов, который начинается в момент принятия решения о необходимости создания ПО и заканчивается в момент прекращения поддержки ПО разработчиками.

Применение SDLC позволяет:

1. Визуализировать сложный процесс разработки
2. Управлять проектом
3. Предсказывать и планировать доставку рабочих продуктов в ходе всего процесса разработки
4. Управлять рисками выхода за рамки бюджета / превышения срока реализации
5. Быстро определять, на каком этапе находится разработка в данный момент

В статье рассмотрим основные этапы жизненного цикла разработки ПО (SDLC) и их предназначение.

Этапы жизненного цикла разработки ПО

Всего выделяют 7 основных этапов разработки [1]:

Жизненный Цикл ПО. Уроки по тестированию. Обучение Junior qa

1. Идея
2. Определение требований
3. Дизайн (архитектура) системы
4. Разработка
5. Тестирование
6. Развертывание
7. Поддержка

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

Этап 1: Идея

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

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

После генерации идей они анализируются, оцениваются и выбирается одна, которую будут «прорабатывать».

Этап 2: Определение требований

На этом этапе “идея” принимает более осмысленный и конкретный вид.

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

Бизнес-аналитики (BA) прорабатывают полученную информацию, детализируют ее и преобразовывают в технические требования к системе. Эти требования называются Software Requirement Specification (SRS).

Кроме SRS на этом этапе:

1. Определяются требования к качеству (SQA, Software Quality Attributes)
2. Проводится анализ рисков (RA, Risk Analysis)
3. Создаются планы валидации и верификации (V “Разработка” -> “Тестирование” -> “Развертывание”.

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

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

   Видео 22. Жизненный цикл ПО. Этапы разработки ПО. Классическая модель разработки ПО

   Именно на этом этапе умирает большинство стартапов.

   Дополнительный этап: Закрытие

   

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

   Как пример, можно вспомнить браузер Internet Explorer (был замен на Edge) или Windows XP (заменена на Windows 7).

   Длительность разработки ПО

   Для простых проектов разработка длится несколько месяцев (например, не “взлетевшие” стартапы, небольшие сайты, и т.п.).

   Для сложных — более 15 лет (например, ПО для космических аппаратов).

   Но, для большинства проектов, активная разработка продолжается на протяжении 6-8 лет. [2]

   Учитывайте это, когда устраиваетесь на работу

   Резюме

   В статье мы разобрались, что такое жизненный цикл разработки ПО (SDLC), рассмотрели его этапы и их особенности.

   Обзор жизненного цикла разработки программного обеспечения (SDLC)

   

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

   Основные модели разработки включают водопадную модель, инкрементную модель, спиральную модель, фонтанную модель, интеллектуальную модель, V-модель, модель RAD, модель CBSD, метод прототипа, метод XP, метод RUP и т. д.

   Модель водопада

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

   

   • План программного обеспечения : в основном определяют цели разработки и осуществимость программного обеспечения.
   • Анализ требований : после подтверждения того, что разработка программного обеспечения осуществима, выполните подробный анализ различных функций, которые должно выполнять программное обеспечение. Этап анализа требований является очень важным этапом. Хорошая работа на этом этапе заложит хорошую основу для успеха всего проекта разработки программного обеспечения.
   • Дизайн программного обеспечения : проектируйте всю программную систему, например, структуру системы, дизайн базы данных и т. д., на основе результатов анализа спроса. Дизайн программного обеспечения обычно делится на общий дизайн (набросок) и детальный дизайн.
   • Программный код : преобразование результата проектирования программного обеспечения в программный код, который может быть запущен на компьютере. В процессе программирования должна быть сформулирована унифицированная и соответствующая стандарту спецификация программирования, чтобы обеспечить удобочитаемость программы, простоту обслуживания и повышение эффективности работы программы.
   • Тестирование программного обеспечения : после того, как разработка программного обеспечения завершена, оно должно пройти тщательное тестирование, чтобы найти и исправить проблемы в программном обеспечении на протяжении всего процесса проектирования. В процессе тестирования необходимо установить подробный план тестирования и проводить тесты в строгом соответствии с планом тестирования для снижения произвольности тестирования. Обслуживание программного обеспечения:
   • Сопровождение программного обеспечения — самый длительный период в жизненном цикле программного обеспечения. После того, как программное обеспечение разработано и введено в эксплуатацию, по разным причинам оно не может продолжать удовлетворять требования пользователей. Чтобы продлить срок службы программного обеспечения, его необходимо поддерживать.

   Модель трансформации

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

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

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

   

   Модель фонтана

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

   

   V модель

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

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

   

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

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

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

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

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

   

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

   Модель RAD — это «высокоскоростной» вариант водопадной модели, который быстро развивается благодаря широкому использованию повторно используемых компонентов и метода построения на основе компонентов. Если требования хорошо понятны, а объем проекта ограничен, эту модель можно использовать для быстрого создания полнофункциональной «информационной системы».

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

   

   Задачи, которые необходимо выполнить в каждый период активности модели RAD, следующие.

   Бизнес-моделирование: какая информация управляет работой бизнес-процесса? Какая информация должна быть сформирована? Кто его сгенерировал? Куда идет информационный поток? Кто справится с этим?

   Могут быть дополнены диаграммами потоков данных.

   Моделирование данных: чтобы поддерживать поток данных бизнес-процесса, найдите набор объектов данных, определите атрибуты объектов данных и сформируйте модель данных с отношениями с другими объектами данных, которые могут быть дополнены диаграммами ER. .

   Моделирование процессов: позволяет объектам данных выполнять различные бизнес-функции в информационном потоке. Процесс создания описывает добавление, изменение, удаление и поиск объектов данных, то есть уточнение блока обработки на диаграмме потока данных.

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

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

   Компонентная модель

   Компонент (Component) — программная единица с многократно используемым значением и относительно независимыми функциями. Модель разработки программного обеспечения на основе компонентов (CBSD) заключается в использовании модульного подхода для разделения всей системы на модули и при поддержке определенной модели компонентов повторное использование одного или нескольких программных компонентов в библиотеке компонентов путем их комбинирования Процесс создания прикладного программного обеспечения системы с высокой эффективностью и высоким качеством.

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

   

   Метод прототипа

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

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

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

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

   

   XP-метод

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

   

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

   Метод единого процесса (УП)

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

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

   Узнать больше

   • Что такое модель программного процесса?
   • Адаптивное и прогнозное планирование: когда Agile? Когда Водопад?
   • Что такое жизненный цикл разработки программного обеспечения?
   • Руководства по обучению скраму
   • Руководства по обучению управлению проектами
   • Что такое УМЛ?
   • Что такое гибкая разработка программного обеспечения?
   • История пользователя и вариант использования для гибкой разработки программного обеспечения

   Источник: www.cybermedian.com

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

   

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

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

   Понятие разработки

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

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

   Жизненный цикл – это…

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

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

   Основной состав

   Жизненный цикл (ЖЦ) обычно включает в себя:

   • подготовку;
   • проектирование;
   • поддержку;
   • написание (непосредственное создание).

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

   1. Приобретение. Так характеризуются действия заказчика, позволяющие сформировать требования и ограничения к желаемой программе. Пример – заключение договора на разработку ПОЮ анализ и аудит выполненных задач. Результатом станет получение готового продукта.
   2. Поставку. Представлена мероприятиями, организованными специалистами. Работники анализируют выдвинутые клиентские требования, создают приложение, подводят итоги. После этого осуществляется решение вопросов, связанных с непосредственным программированием. Завершается проверкой (так называют тестирование) и поставкой программы.
   3. Разработку. Это – комплекс мероприятий, характеризующийся написанием программного кода и формированием дизайна.
   4. Эксплуатацию. Здесь начинается использование готового приложения.
   5. Сопровождение. Поддержка пользователей по мере необходимости. Разработчики будут заниматься исправлением ошибок и возникающих неполадок.

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

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

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

   Ключевые модели

   Существуют различные виды ЖЦ. Они меняются в зависимости от конкретного приложения. Если уточнить особенности каждого варианта, получится выбрать оптимальное решение для создания ПО.

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

   • модель кодирования и устранения ошибок;
   • водопадная модель;
   • разработка через тестирование;
   • инкрементная модель;
   • итерационная модель;
   • спиральная модель;
   • модель «хаоса»;
   • разработка через прототипирование.

   Далее каждый вариант будет рассмотрен детально. А еще – сравнение для тех или иных целей разработки.

   «Водопад»

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

   

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

   • управление проектом;
   • оценка и манипуляция качеством;
   • верификация;
   • аттестация;
   • менеджмент конфигурации;
   • разработка документации.

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

   Главные фазы этой системы обычно следующие:

   • анализ требований;
   • проектирование;
   • кодирование (программирование);
   • тестирование и отладка;
   • эксплуатация и сопровождение.

   Грамотная организация каскадной системы сделает разработку быстрой, эффективной и понятной. Она существует с 1970-х годов.

   Плюсы и минусы

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

   К преимуществам каскадной модели относят:

   1. Стабильность требований. Они будут едиными на протяжении всего жизненного цикла разработки.
   2. Каждая стадия приводит к формированию законченного набора проектной документации. Она будет полной и согласованной.
   3. Все фазы модели определены и понятны. Они с легкостью применяются на практике.
   4. В процессе работы с этой моделью можно предсказать, когда начнется релиз и эксплуатация программы.

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

   Недостатки здесь тоже есть:

   1. Динамические изменения невозможны. А еще здесь трудно сформулировать четкие требования.
   2. Низкая гибкость в управлении проектом.
   3. Линейная структура процесса разработки при обнаружении ошибок приводит к увеличению затрат и нарушению установленных изначально сроков реализации продукта.
   4. Промежуточные приложения нельзя использовать. Они не будут работать.
   5. Отсутствие гибкости моделирования уникальных систем.
   6. Проблемы, связанные со сборкой, обнаруживаются на завершающих этапах разработки.
   7. Отсутствие гарантий качестве главного (итогового) продукта до того момента, как завершится «жизнь» проекта. Пока он не будет «собран», неизвестно, что получится в итоге.
   8. Каждая фаза – это предпосылка для выполнения последующих операций. Это повышает риски для систем без аналогов. Связан соответствующий момент с отсутствием гибкого моделирования.

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

   Область применения