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

Software Development Life Cycle, SDLC — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации

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

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

• Анализ (подготовка)
• Проектирование
• Создание (программирование)
• Тестирование
• Внедрение
• Сопровождение

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

В реальности жизнь продукта редко соответствует какой-либо модели.

Парадигмы и модели разработки ПО

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

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

Code and Fix

Являлась первой моделью разработки ПО.

Этапы модели:

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

Повторяем цикл до полного удовлетворения заказчика (или пока у него не кончатся деньги или терпение)

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

Waterfall Model или «водопад»

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

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

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

Недостатки:

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

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

V-Model (разработка через тестирование)

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

Жизненный цикл проекта

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

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

Недостатки:

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

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

Iterative Model — Итерационная (итеративная) модель

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

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

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

Недостатки:

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

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

Incremental Model

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

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

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

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

Недостатки:

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

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

Spiral Model

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

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

Спиральная модель предполагает 4 этапа для каждого витка:

1. планирование;
2. анализ рисков;
3. конструирование;
4. оценка результата и при удовлетворительном качестве переход к новому витку.

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

• Управлению рисками уделяется особое внимание;
• Дополнительные функции могут быть добавлены на поздних этапах;
• Есть возможность гибкого проектирования.

Недостатки:

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

Модель хаоса

Chaos model

Её создатель Л.Б.С.Ракун отмечает, что такие модели управления проектами, как спиральная модель и каскадная модель, хотя и хороши в управлении расписаниями и персоналом, не обеспечивают методами устранения ошибок и решениями других технических задач, не помогают ни в управлении конечными сроками, ни в реагировании на запросы клиентов. Модель хаоса — это инструмент пытающийся помочь понять эти ограничения и восполнить пробелы.

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

Гибкая (Agile) модель

Agile Model — гибкая модель разработки, по которой сегодня работает большинство ИТ-проектов.Представляет собой совокупность различных подходов к разработке ПО.

Основные идеи Agile:

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

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

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

Недостатки:

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

Гибкие методологии разработки ПО

• SCRUM
• Kanban (看板)
• RUP (Rational Unified Process)
• OpenUP
• DSDM (Dynamic Systems Development Model)
• RAD (Rapid Application Development)
• XP (Extreme Programming)
• FDD (Feature Driven Development)
• ASD (Adaptive Software Development)
• DevOps (Development and Operations)
• DAD (Disciplined Agile Delivery)
• Lean SD (Lean Software Development)
• MDD (Model-Driven Development)
• MSF (Microsoft Solutions Framework)
• PSP (Personal Software Process)
• SAFe (Scaled Agile Framework)
• UP (Unified Process)

1. Agile манифест↩︎
2. Модели жизненного цикла, принципы и методологии разработки ПО↩︎
3. Модели и методологии разработки ПО↩︎
4. Ещё раз про семь основных методологий разработки↩︎

Источник: baikov.dev

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

Слайд 1Лекция 2. Жизненный цикл программного обеспечения
Учебные вопросы:

1. Понятие и основные

процессы жизненного цикла (ЖЦ) программного обеспечения (ПО).
2. Стадии ЖЦ ПО.
3.

Слайд 2Процессы жизненного цикла ПО

Слайд 3
Задачи, решаемые в основных процессах

Слайд 4
Задачи, решаемые во вспомогательных процессах

Слайд 5
Задачи, решаемые в организационных процессах

Слайд 6Стадия формирования требований к ПО —
планирование и анализ требований

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

объекта (организации)

построение моделей деятельности организации:

— модели «AS-IS» («как есть»)

— модели » TO-BE» («как должно быть»)

Слайд 7Стадия проектирования
Этапы (рабочие процессы)
разработка системного проекта
разработка технического проекта

технический проект
техническое задание

Слайд 8Стадия реализации
Этапы (рабочие процессы)
рабочее проектирование
физическое проектирование
программирование
Разработка

и настройка программ, написание программного кода, наполнение баз данных, создание

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

Слайд 9Стадия внедрения
Этапы (рабочие процессы)
тестирование
ввод в действие
Комплексная отладка подсистем

ИС, тестирование, обучение персонала, поэтапное внедрение ИС в эксплуатацию по

подразделениям экономического объекта, оформление акта о приемо-сдаточных испытаниях ИС.

Слайд 10Стадия эксплуатации и сопровождения
Этапы (рабочие процессы)
сопровождение
модернизация
Сбор рекламации и статистики о

функционировании ИС, исправление ошибок и недоработок, оформление требований к модернизации

ИС и ее выполнение (повторение стадий 2 — 5).

Слайд 11
Каскадная схема разработки ПО

Слайд 12Реальный процесс разработки ПО

Слайд 13Спиральная модель жизненного цикла ПО

Похожие презентации

Обратная связь

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

Что такое TheSlide.ru?

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

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

Лекция 2 Модели процессов жизненного цикла систем и программных средств

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

Старейшей парадигмой процесса разработки ПО является классический жизненный цикл (автор Уинстон Ройс, 1970).

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

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

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

Анализ требований относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Рис. 1 — Классический жизненный цикл разработки ПО

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

• архитектуры ПО;
• модульной структуры ПО;
• алгоритмической структуры ПО;
• структуры данных;
• входного и выходного интерфейса (входных и выходных форм данных).

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

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

Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение — это внесение изменений в эксплуатируемое ПО. Цели изменений:

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

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

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

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

Недостатки классического жизненного цикла:

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

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

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

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

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

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

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

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

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

Инкрементная модель является классическим примером инкрементной стратегии конструирования.

Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования.

Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте — более сложные возможности редактирования и документирования; в 3-м инкременте — проверку орфографии и грамматики; в 4-м инкременте — возможности компоновки страницы.

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

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

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

Эволюционная модель ЖЦ

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

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

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

Развитием этой модели является модель эволюционного прототипирования в рамках всего ЖЦ разработки. В литературе она часто называется моделью быстрой разработки приложений RAD (Rapid Application Development). В данной модели приведены действия, которые связаны с анализом ее применимости для конкретного вида системы, а также обследование заказчика для определения потребностей пользователя для разработки плана создания прототипа.

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

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

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

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

1 — начальный сбор требований и планирование проекта;

2 — та же работа, но на основе рекомендаций заказчика;

3 — анализ риска на основе начальных требований;

4 — анализ риска на основе реакции заказчика;

5 — переход к комплексной системе;

6 — начальный макет системы;

7 — следующий уровень макета;

8 — сконструированная система;

9 — оценивание заказчиком

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

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

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

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

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

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

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

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

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

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

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

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

3) включает шаг системного подхода в итерационную структуру разработки;

4) использует моделирование для уменьшения риска и совершенствования программного изделия.

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

1) новизна (отсутствует достаточная статистика эффективности модели);

2) повышенные требования к заказчику;

3) трудности контроля и управления временем разработки.

Экстремальное программирование (eXtreme Programming, XP) — облегченный (подвижный) процесс (или методология), главный автор которого — Кент Бек (1999) [11]. ХР-процесс ориентирован на группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требований. ХР-группу образуют до 10 сотрудников, которые размещаются в одном помещении.

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

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

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

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

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

2. Частая смена версий (Small releases) — быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.

3. Метафора (Metaphor) — вся разработка проводится на основе простой, общедоступной истории о том, как работает вся система.

4. Простое проектирование (Simple design) — проектирование выполняется настолько просто, насколько это возможно в данный момент.

5. Тестирование (Testing) — непрерывное написание тестов для модулей, которые должны выполняться безупречно; заказчики пишут тесты для демонстрации законченности функций. «Тестируй, а затем кодируй» означает, что входным критерием для написания кода является «отказавший» тестовый вариант.

6. Реорганизация (Refactoring) — система реструктурируется, но ее поведение не изменяется; цель — устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.

7. Парное программирование (Pair programming) — весь код пишется двумя программистами, работающими на одном компьютере.

8. Коллективное владение кодом (Collective ownership) — любой разработчик может улучшать любой код системы в любое время.

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

10. 40-часовая неделя (40-hour week) — как правило, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ.

11. Локальный заказчик (On-site customer) — в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков.

12. Стандарты кодирования (Coding standards) — должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы.

Карпушева Ирина Александровна

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

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