Характеристики этапов жизненного цикла программы

Содержание

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

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

Различают методы, средства и процедуры ТКПО:

Методы обеспечивают решение следующих задач:

Планирование и оценка проекта

Анализ системных и программных требований

Проектирование алгоритмов, структур данных и программных структур

Средства (утилиты) ТКПО обеспечивают автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами (Computer Aided Software Engineering).

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

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

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

Тема 1.1. Структура жизненного цикла программы.

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

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

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

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

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

SDLС — Жизненный цикл разработки программного обеспечения. Подробный разбор этапов разработки.

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

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

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

ЖЦ таких программных средств составляет 10-20 лет, из которых 70-90% приходиться на эксплуатацию и сопровождение. Вследствии массового тиражирования и длительного сопровождения совокупные затраты в процессе эксплуатации и сопровождения могут значительно превышать затраты на системный анализ и проектирование.

ЖЦ рассматриваемых программ включает в себя следующие основные этапы:

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

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

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

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

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

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

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

Как и любая схема действий классический жизненный цикл имеет достоинства и недостатки.

Достоинства классического ЖЦ: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.

Недостатки классического ЖЦ:

1. реальные проекты часто требуют отклонения от стандартной последовательности шагов

2. цикл основан на точной формулировке исходных требований к ПС (реально в начале проекта требования заказчика определены частично)

3. результаты проекта доступны заказчику только в конце работы.

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

Основная цель макетирования — снять неопределенности в требованиях заказчика.

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

Модель может принимать одну из трех форм:

1) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог);

2) работающий макет (выполняет некоторую часть требуемых функций)

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

Последовательность действий при макетировании:

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

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

Быстрое проектирование приводит к построению макета.

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

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

Достоинство макетирования: обеспечивает определение полных требований к ПО. Недостатки макетирования:

1. заказчик может принять макет за продукт;

2. разработчик может принять макет за продукт.

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

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

Стратегии конструирования ПО.

Существуют 3 стратегии конструирования ПО:

однократный проход (водопадная стратегия) — линейная последовательность этапов конструирования;

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

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

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

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

Быстрая разработка приложений.

Модель быстрой разработки приложений (Rapid Application Development) – второй пример применения инкрементной стратегии конструирования.

RAD-модель обеспечивает экстремально короткий цикл разработки. RAD-высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, Rad-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD-подход ориентирован на разработку информационных систем и выделяет следующие этапы:

бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется инф-ция? Кто генерирует ее? Где инф-ция применяется?

Кто ее обрабатывается?

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

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

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

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

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

Применения RAD имеет и свои недостатки и ограничения.

1. для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп);

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

3. RAD не применима в условиях высоких технических рисков (т.е. при использовании новой технологии).

Спиральная модель – классический пример применения эволюционной стратегии конструирования.

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

Спиральная модель: 1- начальный сбор требований и планирование проекта, 2- та же работа, на основе рекомендаций заказчика, 3- анализ риска на основе начальных требований, 4-анализ риска на основе реакции заказчика, 5- переход к комплексной системе, 6- начальный макет системы, 7-следующий уровень макета, 8- сконструированная система, 9-оценование заказчиком.

Как показано на рисунке, модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

1. планирование – определение целей, вариантов и ограничений.

2. анализ риска – анализ вариантов и распознавание/выбор риска

3. конструирование – разработка продукта следующего уровня

4. оценивание – оценка заказчиком текущих результатов конструирования.

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

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

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

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

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

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

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

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

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

Анализ требований
Фаза планирования
Фаза проектирования продукта
Фаза кодирования
Фаза тестирования
Фаза валидации
Фаза развертывания
Фаза сопровождения

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

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

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

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

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

Фазы SDLC

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

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

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

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

В это время команда разработчиков решает, какой подход к разработке они будут использовать: будут ли они кодировать каждую строчку? Какие языки программирования они будут использовать? Будут ли они использовать no-code инструменты, такие как ? И если они будут использовать такие инструменты, как AppMaster будут ли они редактировать автоматически сгенерированный код?

Ответы на эти вопросы должны быть получены на самом раннем этапе.

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

Попробуйте no-code платформу AppMaster

AppMaster поможет создать любое веб, мобильное или серверное приложение в 10 раз быстрее и 3 раза дешевле

Фаза планирования

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

Архитектура программного обеспечения: базы данных, операционная система, языки программирования, API, фреймворки
Дизайн пользовательского интерфейса
Требования к инфраструктуре
Безопасность ( SSL шифрование и сертификат, защита паролем и многое другое).

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

Фаза проектирования

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

UI: как пользователь будет взаимодействовать с платформой;
Программирование: какой подход вы будете использовать (код или визуальное программирование, какой язык программирования, какой no-code инструмент)
Связь: как программное обеспечение будет взаимодействовать с другими активами
Платформы: на каких платформах будет размещаться программное обеспечение
Безопасность: какие меры вы собираетесь принять для обеспечения безопасности вашего программного обеспечения?

Фаза кодирования

Фаза кодирования — это то место, где разработчики программного обеспечения фактически начинают создавать программное обеспечение. Если они выбрали наиболее традиционный подход, то именно здесь они начинают писать код. Если они выбрали другой подход, например low-code или no-code , то здесь они начинают использовать выбранную no-code платформу, например, AppMaster и начинают собирать готовые программные блоки для разработки своего программного продукта.

Фаза тестирования

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

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

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

Фаза валидации

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

Фаза развертывания

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

Фаза сопровождения

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

Попробуйте no-code платформу AppMaster

AppMaster поможет создать любое веб, мобильное или серверное приложение в 10 раз быстрее и 3 раза дешевле

Отказ от ответственности

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

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

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

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

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

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

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

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

3. Написание кода

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

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

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

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

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

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

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

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

Технические проблемы, которые встречаются при разработке ПО

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

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

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

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

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

Хотя это не исключает, но заметно снижает угрозы.

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

Подходы к разработке ПО

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

Code and fix — написание кода и устранение багов в нем;
Waterfall Model — каскад или “водопад”;
V-model — разработка через тестирование;
Incremental Model — инкрементная модель;
Iterative Model — итеративная модель;
Spiral Model — спиральная модель;
Agile Model — гибкая методология разработки.

Модель code and fix самая простая. Разработчик пишет программный код, запускает его. Затем смотрит, как он работает. При обнаружении бага устраняет его. Скорее всего, эту модель вы уже освоили, поэтому давайте перейдем к остальным.

Источник: javarush.com