Что понимают под моделью жизненного цикла разработки программного продукта

ГЛАВА 3. Модели жизненного цикла программного продукта

3.1 Определение модели ЖЦ АИС

Под моделью жизненного цикла разработки программного продукта понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла разработки программного продукта. Наибольшее распространение получили следующие модели жизненного цикла разработки программного продукта (таблица1. Краткие характеристики моделей жизненного цикла АИС): каскадная модель, или водопад (waterfall model); v-образная модель (v-shaped model); модель прототипирования (prototype model); модель быстрой разработки приложений, или RAD-модель (RAD-rapid application development model);многопроходная модель (incremental model); спиральная модель (spiral model).

Таблица 1.Краткие характеристики каждой из перечисленных моделей

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

В однородных информационных системах 1970-х и 1980-х годов прикладные программные продукты представляли собой единое целое. Для разработки такого типа программного продукта применялось каскадная модель, или «водопад».

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

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

3.3 V-образная модель

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

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

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

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

Модель включает в себя следующие фазы:

Составление требований к проекту и планирование – определяются системные требования и выполняется планирование работ;

Составление требований к продукту и их анализ – составляется полная спецификация требований к программному продукту;

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

Детальное проектирование – определяется алгоритм работы каждого компонента;

Кодирование – выполняется преобразование алгоритмов в готовое программное обеспечение;

Модульное тестирование – выполняется проверка каждого компонента или модуля программного продукта;

Интеграционное тестирование – осуществляются интеграция программного продукта и его тестирование;

Системное тестирование – выполняется проверка функционирования программного продукта после помещения его в аппаратную среду в соответствии со спецификацией требований;

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

Рис.5 V-образная модель

Преимущества v-образной модели:

1) Большая роль придается верификации и аттестации программного продукта, начиная с ранних стадий его разработки, все действия планируются;

2) Предполагаются аттестация и верификация не только самого программного продукта, но и всех полученных внутренних и внешних данных;

3) Ход выполнения работы может легко отслеживаться, так как завершение каждой фазы является контрольной точкой.

Кроме перечисленных достоинств модель обладает и рядом недостатков:

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

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

3.4 Модель прототипирования

Рис.6 Модель прототипирования

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

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

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

Модель протипирования обладает целым рядом преимуществ:

1) Взаимодействие заказчика с разрабатываемой системой начинается на раннем этапе;

2) Благодаря реакции заказчика на прототип сводится к минимуму число неточностей в требованиях;

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

4) В процессе разработки всегда можно учесть новые, даже неожиданные требования заказчика;

5) Прототип представляет собой формальную спецификацию, воплощенную в программный продукт;

6) Прототип позволяет очень гибко выполнять проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла разработки;

7) Заказчик всегда видит прогресс в процессе разработки программного продукта;

8) Возможность возникновения противоречий между разработчиками и заказчиками сведена к минимуму;

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

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

1) Решение сложных задач может отодвигаться на будущее;

2) Заказчик может предпочесть получить прототип, а не законченную полную версию программного продукта;

3) Прототипирование может неоправданно затянуться;

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

Модель прототипирования рекомендуется применять в следующих случаях:

1) Требования к программному продукту заранее неизвестны;

2) Требования не постоянны или неудачно сформулированы;

3) Требования необходимо уточнить;

4) Нужна проверка концепции;

5) Существует потребность в пользовательском интерфейсе;

6) Выполняется новая, не имеющая аналогов разработка;

7) Разработчики не уверены в том, какое решение следует выбрать.

3.5 Модель быстрой разработки приложений (RAD-модель)

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

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

На рисунке (рис.7), поясняющем принцип RAD-модели, указаны этапы процесса разработки и отображено участие заказчиков (штриховая линия) на каждом из них.

Модель включает в себя следующие фазы:

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

Создание – детальное проектирование, кодирование и тестирование программного продукта, а также поставка его заказчику;

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

Модель обладает следующими достоинствами:

1) Использование современных инструментальных средств позволяет сократить время цикла разработки;

2) Привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым программным продуктом;

3) Повторно используются компоненты уже существующих программ.

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

1) Если заказчики не могут постоянно участвовать в процессе разработки, то это может негативно сказаться на программном продукте;

2) Для работы нужны высококвалифицированные кадры, умеющие пользоваться современными инструментальными средствами;

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

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

Рис.7 Модель быстрой разработки приложений

3.6 Многопроходная модель

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

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

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

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

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

Рис.8 Многопроходная модель

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

Рис.9 Спиральная модель

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

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

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

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

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

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

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

Рис.10 Улучшенная спиральная модель с указанием вспомогательных процессов

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

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

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

Работа состоит из трех глав.

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

Наибольшее распространение получили две основные модели ЖЦ:

· каскадная модель (70-85 гг.);

· спиральная модель (86-90 гг.).

Структура жизненного цикла базируется на трех группах процессов:

· основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение);

· вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, аттестация, аудит, решение проблем);

· организационные процессы (управление проектами, создание инфраструктуры проекта, улучшение самого жизненного цикла, обучение).

Под термином CASE (Computer Aided Software Engineering) понимаются программные средства, поддерживающие процессы создания и сопровождения автоматизированной системы включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным программным обеспечением и техническими средствами образуют полную среду разработки АС.

Под моделью жизненного цикла разработки программного продукта понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла разработки программного продукта. Наибольшее распространение получили следующие модели жизненного цикла разработки программного продукта: каскадная модель, или водопад (waterfall model); v-образная модель (v-shaped model); модель прототипирования (prototype model); модель быстрой разработки приложений, или RAD-модель (RAD-rapid application development model); многопроходная модель (incremental model); спиральная модель (spiral model).

Список использованной литературы

1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2000. – 352с.

2. Канер С., Фолк Д., Кен Нгуен Е. Тестирование программного обеспечения: Пер. с англ. – Киев: ДиаСофт, 2000. – 544с.

3. Соммервилл И. Инженерия программного обеспечения. – М.: СПБ.: Киев: Изд. дом «Вильямс», 2002. – 624с.

4. Фридман А.Л. Основы объектно-ориентированной разработки программных систем. – М.: Финансы и статистика, 2000. – 200с.

5. Гагарина Л.Г. Основы технологии и разработки программных продуктов: Учебник – М ФОРУМ – ИНФРА – М. 2006.

6. Семенов М.И. Трубилин И.Т., Лойко В.И. Барановская Т.П. Архитектура компьютерных систем и сетей Учебное пособие – М Финансы и статистика, 2004. – 320с.

7. Советов Б.Я. Цеханковский В.В. Информационные технологии – М Высшая школа, 2003.

8. Информатика: Учебник под редакцией Макаровой Н.В. – М.:Финансы и статистика., 2005. – 480с.

Источник

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

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

Что такое SDLC

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

Его функции – регламентирование и формализация процесса разработки. Это важно при командной работе, когда задействуют десятки специалистов.

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

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

Каскадная

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

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

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

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

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

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

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

Спиральная

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

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

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

V-образная

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

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

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

Итеративная

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Виджеты Calltouch

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник