Жизненный цикл программы что это такое

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Жизненный цикл разработки. SDLC (2020)

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

Источник: it-black.ru

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

Чтобы разработать программное обеспечение, нужно использовать специальный алгоритм. Его называют SDLC (Software Life Cycle Model), или жизненный цикл ПО. Это своеобразная основа, которая делает процесс разработки последовательным и упрощает техническую поддержку масштабных IT-проектов. В статье расскажем, что такое SDLC, перечислим его основные этапы и модели.

Оптимизируйте маркетинг и увеличивайте продажи вместе с Calltouch

Что такое SDLC

SDLC – это алгоритм создания IT-продукта, который состоит из 6 этапов и охватывает период с момента принятия решения о его разработке и заканчивается, когда ПО перестают использовать. Каждый этап опирается на результат предыдущего и дает пул необходимых указаний для выполнения последующего. Его функции – регламентирование и формализация процесса разработки. Это важно при командной работе, когда задействуют десятки специалистов.

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

Есть 5 моделей жизненного цикла программного обеспечения. Чаще используют каскадную, инкрементную и спиральную. V-образная и итеративная пользуются меньшим спросом в силу своей «неуниверсальности».

Каскадная

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

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

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

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

Инкрементная

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

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

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

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

Бизнес

Как оценить стоимость бизнеса: методы расчета и подходы

Как оценить стоимость бизнеса: методы расчета и подходы

Спиральная

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

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

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

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

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

V-образная

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

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

Применение V-модели оправдывает себя при разработке надежных и точных продуктов. Например, систем видеонаблюдения.

Итеративная

Преимущество этой модели в том, что она позволяет «ориентироваться на местности» – заранее определять закрытый список требований и составлять объемное техническое задание не нужно. Выявить актуальность и полезность продукта, а также возможные ошибки можно на этапе черновика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проектирование. Этот этап нужен для того, чтобы ответить следующие вопросы:

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

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

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

Виджеты Calltouch

• Увеличьте конверсию сайта на 30%
• Обратный звонок, промо-лендинги, формы захвата, мультикнопка, автопрозвон форм

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

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

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

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

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

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

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

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

Виджет обратного звонка для сайта

• Повысьте конверсию сайта на 30%
• Новым клиентам 50 минут в подарок

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

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

Бизнес

Лучшие корпоративные мессенджеры: как выбрать чат для сотрудников

Лучшие корпоративные мессенджеры: как выбрать чат для сотрудников

Коротко о главном

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

Источник: www.calltouch.ru

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

Следует начать с определения, Жизненный цикл программного обеспечения (Software Life Cycle Model) — это период времени, который начинается с момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

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

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

Каскадная модель

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

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

Жизненный цикл традиционно разделяют на следующие основные этапы :

1. Анализ требований,
2. Проектирование,
3. Кодирование (программирование),
4. Тестирование и отладка,
5. Эксплуатация и сопровождение.

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

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

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

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

Область применения Каскадной модели

Ограничение области применения каскадной модели определяется её недостатками. Её использование наиболее эффективно в следующих случаях:

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

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

(поэтапная модель с промежуточным контролем)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Применение спиральной модели целесообразно в следующих случаях:

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

Источник: qaevolution.ru

Жизненный Цикл Разработки ПО (SDLC)

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

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

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

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

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

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

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 “Разработка” -> “Тестирование” -> “Развертывание”.

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

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

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

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

   

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

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

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

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

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

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

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

   Резюме

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

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

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

   FAQ

   Что такое SDLC?

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

   Какие основные этапы SDLC?

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

   Источник: beqa.pro

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

   Источник нашей мудрости — наш опыт, источник нашего опыта — наша глупость.

   Саша Гитри, французский актер, режиссер

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

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

   Существенный качественный скачок стал возможен в семидесятых годах прошлого столетия. В 1969 году Эдсгер Дейкстра опубликовал статью «Структурное программирование » [3]. Это событие ознаменовало начало десятилетия напряжённого труда над инженерными методами, которые в корне изменили представления о подходах и тех возможностях, что открыты человеку в сфере разработки программного обеспечения ( ПО ). Благодаря структурному программированию и правильно поставленному процессу пошаговой разработки стало возможным создание действительно больших программных систем.

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

   1.1. Общее описание жизненного цикла

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

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

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

   На данный момент можно выделить следующие часто упоминаемые и используемые модели жизненного цикла:

   • каскадная модель;
   • процессная или поэтапная модель с промежуточным контролем;
   • итерационная модель.

   1.2. Каскадная модель

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

   

   
   Рис. 1.1. Каскадная (водопадная) модель ЖЦ разработки

   Марри Кантор [7] отмечает ряд важных аспектов, характерных для каскадной модели. Каскадная схема включает несколько важных операций, применимых ко всем проектам:

   • составление плана действий по разработке системы;
   • планирование работ, связанных с каждым действием;
   • применение контрольных этапов отслеживания хода выполнения действий.

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

   В результате можно выделить следующие положительные стороны применения каскадного подхода:

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

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

   «Основное заблуждение каскадной модели состоит в предположениях, что проект проходит через весь процесс один раз, архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации устраняются по мере тестирования. Иными словами, каскадная модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит во время тестирования компонентов и системы» [10].

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

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

   

   
   Рис. 1.2. Поэтапная модель с возвратами

   Одним интересным вариантом развития поэтапной модели является V-образный жизненный цикл (рис. 1.3). В этой модели акцент делается на работы, связанные с верификацией документов разработки. Нисходящая ветвь модели описывает собственно разработку программной документации: требования к ПО, функции программных элементов, архитектуру — связи программных функций, программный код. Восходящая ветвь — этапы верификации.

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

   Источник: intuit.ru