Международный стандарт ISOIES 12207 регламентирует структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания программного обеспечения. По этому стандарту жизненный цикл программного обеспечения базируется на трех группах процессов:
- основные процессы жизненного цикла, то есть приобретение, поставка, разработка, эксплуатация и сопровождение;
- вспомогательные процессы, обеспечивающие выполнение основных процессов, то есть документирование, верификация, аттестация, оценка качества и другие;
- организационные процессы, то есть управление проектами, создание инфраструктуры проекта и обучение.
Разработка включает в себя все работы по созданию программного обеспечения в соответствии с заданными требованиями. Сюда включаются оформление проектной и эксплуатационной документации, подготовка материалов, необходимых для проверки работоспособности и качества программных продуктов.
Основные этапы процесса разработки:
- анализ требований заказчика;
- проектирование;
- реализация (программирование).
Процесс эксплуатации включает в себя работы по внедрению программного обеспечения в эксплуатацию, в том числе конфигурирование рабочих мест, обучение персонала, локализация проблем эксплуатации и устранение причин их возникновения, модификация программного обеспечения в рамках установленного регламента и подготовка предложений по модернизации системы.
Каждый процесс характеризуется определенными задачами и методами их решения, а также исходными данными и результатами.
Жизненный цикл программного обеспечения носит, как правило, итерационный характер, то есть реализуются этапы, начиная с самых ранних, которые циклически повторяются в соответствии с изменением требований внешних условий и введением ограничений.
Модели жизненного цикла программного обеспечения
Существует несколько моделей жизненного цикла, которые определяют порядок исполнения этапов разработки и критерии перехода от этапа к этапу. К настоящему времени наибольшее распространение получили две модели жизненного цикла: каскадная и спиральная.
В существующих ранее однородных информационных системах каждое приложение представляло собой единое целое. Для разработки таких приложений применялась каскадная модель жизненного цикла, которую также называют классической или водопадной.
При использовании каскадной модели разработка рассматривалась как последовательность этапов, причем переход на следующий более низкий этап происходит только после того, как полностью завершены все работы на текущем этапе. Подразумевается, что в каскадной модели разработка начинается на системном уровне и происходит через анализ, проектирование, кодирование, тестирование и сопровождение.
Рисунок 1– Основные этапы разработки каскадной модели
1. Системный анализ задает роль каждого элемента в компьютерной системе и взаимодействие элементов друг с другом. Поскольку программное обеспечение рассматривается как часть большой системы, то анализ начинается с определения требований по всем системным элементам. Необходимость системного анализа явно проявляется, когда формируется интерфейс программного обеспечения с другими элементами, т.е. с аппаратурой или базами данных. На этом же этапе начинается решение задач планирования проекта. В ходе планирования проекта определяется объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.
Анализ требований относится к отдельному программному элементу. На этом этапе уточняются и детализируются функции каждого элемента, его характеристики и интерфейс. На этом же этапе завершается решение задачи планирования проекта.
2. Проектирование состоит в создании:
- архитектуры программного обеспечения;
- модульной структуры программного обеспечения;
- алгоритмической структуры программного обеспечения;
- структуры данных;
- входного/выходного интерфейса (входных/выходных форм данных).
При решении задач проектирования основное внимание уделяется качеству будущего программного продукта.
3. Кодирование или разработка состоит в переводе результатов проектирования в код программы.
4. Тестирование – это выполнение программы на выявление дефектов в функциях, логике и форме реализации программного продукта.
5. Сопровождение – это внесение изменений в эксплуатируемое программное обеспечение с целью:
- исправления ошибок;
- адаптации к изменениям внешней для программного обеспечения среды;
- усовершенствование программного обеспечения в соответствии с требованиями заказчика.
Достоинства применения каскадной модели:
- дает план и временной график по всем этапам проекта, упорядочивая, таким образом, ход разработки;
- на каждом этапе формируется законченный набор проектной документации, проверенный на полноту и согласованность;
- выполняемые в логической последовательности этапы работы позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадная модель хорошо себя зарекомендовала при построении информационных систем, для которых в самом начале разработки можно достаточно точно сформулировать все требования в системе, например, сложные расчетные системы, различные системы реального времени и т.д.
Недостатки каскадной модели:
- реальные проекты часто требуют отклонений от стандартной последовательности шагов;
- каскадная модель основана на точной формулировке исходных требований к программному обеспечению, однако реально в ряде случаев в начале проекта требования заказчика определены только частично;
- результаты реализации проекта доступны заказчику только после завершения всех работ.
Из-за необходимости в процессе создания программного обеспечения постоянного возврата к предыдущим этапам и уточнения или пересмотра ранее принятых решений реальный процесс разработки программного обеспечения на основе каскадной модели может быть представлен следующей схемой (рис.2).
Рисунок 2 – Процесс разработки программного обеспечения на основе каскадной модели
Ограничение области применения каскадной модели определяется ее недостатками. Ее использование наиболее эффективно в следующих случаях:
- при разработке проектов с четкими, неизменяемыми в течение ЖЦ требованиями, понятными реализацией и техническими методиками;
- при разработке проекта, ориентированного на построение системы или продукта такого же типа, как уже разрабатывались разработчиками ранее;
- при разработке проекта, связанного с созданием и выпуском новой версии уже существующего продукта или системы;
- при разработке проекта, связанного с переносом уже существующего продукта на новую платформу;
- при выполнении больших проектов, в которых задействовано несколько больших команд разработчиков.
Спиральная модель жизненного цикла
Спиральная модель является классическим примером эволюционной стратегии конструирования программного обеспечения.
Спиральная модель базируется на лучших свойствах каскадной модели жизненного цикла и макетирования, к которым добавляется анализ риска.
Спиральная модель включает четыре основных этапа, которые периодически повторяются:
- планирование – это определение целей, вариантов и ограничений;
- анализ риска – это анализ вариантов и распознавание риска;
- конструирование – это разработка программного продукта следующего уровня;
- оценивание – это оценка заказчика текущих результатов конструирования.
При движении по спирали строятся все более полные версии программного обеспечения при продвижении от центра к периферии. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, то на помощь заказчику и разработчику приходит макетирование. Заказчик оценивает инженерную или конструкторскую работу и вносит предложения по модификации.
Следующая фаза планирования и анализа риска базируется на предложении заказчика. Если риск слишком велик, проект может быть остановлен. В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. Количество действий по разработке возрастает по мере продвижения от центра спирали.
Рисунок 4 – Этапы спиральной модели
Достоинства спиральной модели:
- наиболее реально отображает процесс разработки программного обеспечения;
- позволяет явно учитывать риск на каждом витке эволюции разработки;
- использует моделирование для уменьшения риска и совершенствования программного продукта.
Недостатки спиральной модели:
- повышенное требование к заказчику;
- трудности контроля и управления временем разработки.
Область применения спиральной модели
Менеджер проекта может быть уверен в целесообразности применения спиральной модели, если для этого существует хотя бы одна из следующего перечня причин:
∙ когда создание прототипа представляет собой подходящий тип разработки продукта;
∙ когда важно сообщить, каким образом будет происходит увеличение затрат, и подсчитать затраты, связанные с выполнением действий из квадранта риска;
∙ когда организация обладает навыками, требуемыми для адаптации модели;
∙ для проектов, выполнение которых сопряжено со средней и высокой степенью риска;
∙ когда нет смыла браться за выполнение долгосрочного проекта из-за потенциальных изменений, которые могут произойти в экономических приоритетах, и когда такая неопределенность может вызвать ограничение во времени;
∙ когда речь идет о применении новой технологии и когда необходимо протестировать базовые концепции;
∙ когда пользователи не уверены в своих потребностях;
∙ когда требования слишком сложные;
∙ при разработке новой функции или новой серии продуктов;
∙ когда ожидаются существенные изменения, например, при изучении или исследовательской работе;
Источник: skarlupka.ru
Спиральная модель жизненного цикла разработки ПО
Спиральная модель воплощает в себе преимущества каскадной модели. При этом в нее также включены анализ рисков, управление ими, а также процессы поддержки и менеджмента.
Здесь также предусмотрена разработка программного продукта при использовании метода прототипирования или быстрой разработки приложений посредством применения языков программирования и средств разработки четвертого поколения (и выше). Модель отображает базовую концепцию, которая заключается в том, что каждый цикл представляет собой набор операций, которому соответствует такое же количество стадий, как и в модели каскадного процесса. Причем принимается во внимание каждая составляющая часть продукта, и каждый уровень сложности, начиная с общей формулировки потребностей и заканчивая кодированием каждой отдельной программы. Рис. 6. Спиральная модель
Стадии разработки спиральной модели
| Обзор моделей жизненного цикла разработки ПО | 28 |
Как показано на рис., в каждый квадрант модели входят целевые и вспомогательные действия. Ниже перечислены эти квадранты. ∙ определение целей, альтернативных вариантов и ограничений.
Выполняется определение целей, таких как рабочая характеристика, выполняемые функции, возможность внесения изменений, решающих факторов достижения успехам и аппаратного/программного интерфейса. Определяются альтернативные способы реализации этой части продукта (конструирование, повторное использование, покупка, субдоговор, и т.п.).
Определяются ограничения, налагаемые на применение альтернативных вариантов (затраты, график выполнения, интерфейс, ограничения, относящиеся к среде и др.). Создается документация, подтверждающая риски, связанные с недостатком опыта в данной сфере, применением новой технологии, жесткими графиками, плохо организованными процессами и т.д.; ∙ оценка альтернативных вариантов, идентификация и разрешение рисков.
Выполняется оценка альтернативных вариантов, относящихся к целям и ограничениям. Выполняется определение и разрешение рисков (менеджмент рисков, методика экономически выгодного выбора источников разрешения, оценка остальных связанных с риском ситуаций, когда деньги могут быть потеряны из-за продолжения разработки системы (решения о прекращении/продолжении работ над проектом, и т.п.); ∙ разработка продукта следующего уровня.
Типичные действия, выполняемые на этой стадии, могут включать в себя создание проекта, критический анализ проекта, разработку кода, проверку кода, тестирование и компоновку продукта. Первая создаваемая версия продукта основывается на том, что попадает в поле зрения заказчика.
Затем начинается фаза планирования: программа возвращается в исходное состояние с целью учета реакции клиента. Каждая последующая версия более точно воплощает требования заказчика.
Степень вносимых изменений от одной версии программы к следующей уменьшается с каждой новой версией, что в конечном счете приводит к получению функциональной системы; ∙ планирование следующей фазы. Типичные действия на этой стадии могут включать в себя разработку плана проекта, разработку плана менеджмента конфигурацией, разработку плана тестирования и разработку плана установки программного продукта.
Чтобы лучше понять спиральную модель, изображенную на рис., нужно начинать с центра в квадранте 1 (определение целей, альтернативных вариантов и ограничений), исследовать риски, составить план их разрешения, подготовиться к следующей итерации и переместиться вправо. Для каждой итерации следует определить цели, альтернативные варианты и ограничения; установить и разрешить риски; дать оценку альтернативным вариантам разработать результативные данные для этой итерации и подтвердить их правильность; спланировать следующую итерацию.
Затем следует выбрать метод осуществления следующей итерации в случае, если требуется ее выполнять. В квадрантах отсутствует заданное количество циклов. Их количество нужно выбрать по необходимости, а итерации можно адаптировать под определенный проект. Следует отметить тот факт, что кодирование выполняется значительно позже, чем в других моделях.
Смысл заключается в том, чтобы минимизировать риск посредством последовательных уточнений требований, выдвигаемых пользователем. В каждом «минипроекте» (движении по спирали) рассматривается один или несколько главных факторов риска, начиная с фактора наивысшего риска. Типичные риски включают в себя неправильно истолкованные требования, архитектуру, потенциальные проблемы, связанные с эксплуатацией продукта, проблемы в базовой технологии и т.д. При использовании принципа прототипирования разработчики могут избегать проверенных практических методов разработки системы и неправильно использовать
| Обзор моделей жизненного цикла разработки ПО | 29 |
модель, мотивируя это причиной разработки «на скорую руку». Надлежащее использование спиральной модели или одного из ее вариантов поможет избежать «хакерства» и нарушения дисциплины. Как показано на рис., после проведения анализа и оценки рисков в большом объеме в «хвосте» спиральной модели изображены этапы процесса, напоминающие каскадную модель. Поскольку спиральная модель была разработана с большей тщательностью, чем другие методики, в разработке по принципу спирали особое внимание уделено оценке альтернативных вариантов и оценке рисков. Критический анализ, осуществляемый в конце каждой фазы, обеспечивает переход к следующей фазе или в случае необходимости определяет потребность в повторном выполнении каждой фазы.
Преимущества спиральной модели
При использовании спиральной модели при выполнении проекта, для которого она в достаточной мере подходит, проявляются следующие преимущества: ∙ спиральная модель разрешает пользователям «увидеть» систему на ранних этапах, что обеспечивается посредством использования ускоренного прототипирования в жизненном цикле разработки ПО; ∙ обеспечивается определение непреодолимых рисков без особых дополнительных затрат; ∙ эта модель разрешает пользователям активно принимать участие при планировании, анализе рисков, разработке, а также при выполнении оценочных действий; ∙ она обеспечивает разбиение большого потенциального объема работы по разработке продукта на небольшие части, в которых сначала реализуются решающие функции с высокой степенью риска, позволяющие устранить необходимость продолжения работы над проектом (таким образом, в случае необходимости становится возможным прекратить работу над проектом, и уменьшаются расходы); ∙ в модели предусмотрена возможность гибкого проектирования, поскольку в ней воплощены преимущества каскадной модели, и в тоже время, разрешены итерации по всем фазам этой же модели; ∙ реализованы преимущества инкрементной модели, а именно выпуск инкрементов, сокращение графика посредством перекрывания инкрементов, рассортированных по версиям, и неизменяемость ресурсов при постепенном росте системы; ∙ здесь не ставится цель выполнить невозможное — довести конструкцию до совершенства; ∙ обратная связь по направлению от пользователей к разработчикам выполняется с высокой частотой и на ранних этапах модели, что обеспечивает создание нужного продукта высокого качества; ∙ происходит усовершенствование административного управления над процессом обеспечения качества, правильностью выполнения процесса разработки, затратами, соблюдением графика и кадровым обеспечением, что достигается путем выполнения обзора в конце каждой итерации; ∙ повышается продуктивность благодаря использованию пригодных для повторного использования свойств; ∙ повышается вероятность предсказуемого поведения системы с помощью уточнения поставленных целей; ∙ при использовании спиральной модели не нужно распределять заранее все необходимые для выполнения проекта финансовые ресурсы; ∙ можно выполнять частую оценку совокупных затрат, а уменьшение рисков связано с затратами.
| Обзор моделей жизненного цикла разработки ПО | 30 |
Недостатки спиральной модели
При использовании спиральной модели относительно проекта, для которого она не подходит в достаточной мере, проявляются следующие недостатки: ∙ если проект имеет низкую степень риска или небольшие размеры, модель может оказаться дорогостоящей. Оценка рисков после прохождения каждой спирали связана с большими затратами; ∙ модель имеет усложненную структуру, поэтому может быть затруднено ее применение разработчиками, менеджерами и заказчиками; ∙ серьезная нужда в высокопрофессиональных знаниях для оценки рисков; ∙ спираль может продолжаться до бесконечности, поскольку каждая ответная реакция заказчика на созданную версию может порождать новый цикл, что отдаляет окончание работы над проектом (принятие общего решения о прекращении процесса разработки); ∙ большое количество промежуточных стадий может привести к необходимости в обработке внутренней дополнительной и внешней документации; ∙ использование модели может оказаться дорогостоящим и даже недопустимым по средствам, так как время, затраченное на планирование, повторное определение целей, выполнение анализа рисков и прототипирование, может быть чрезмерным; ∙ при выполнении действий на этапе вне процесса разработки возникает необходимость в переназначении разработчиков; ∙ могут возникнуть затруднения при определении целей и стадий, указывающих на готовность продолжать процесс разработки на следующей итерации; ∙ отсутствие хорошего средства или метода прототипирования может сделать использование модели неудобным; ∙ в производстве использование спиральной модели еще не получило такого широкого масштаба, как применение других моделей.
Область применения спиральной модели
Менеджер проекта может быть уверен в целесообразности применения спиральной модели, если для этого существует хотя бы одна из следующего перечня причин: ∙ когда создание прототипа представляет собой подходящий тип разработки продукта; ∙ когда важно сообщить, каким образом будет происходит увеличение затрат, и подсчитать затраты, связанные с выполнением действий из квадранта риска; ∙ когда организация обладает навыками, требуемыми для адаптации модели; ∙ для проектов, выполнение которых сопряжено со средней и высокой степенью риска; ∙ когда нет смыла браться за выполнение долгосрочного проекта из-за потенциальных изменений, которые могут произойти в экономических приоритетах, и когда такая неопределенность может вызвать ограничение во времени; ∙ когда речь идет о применении новой технологии и когда необходимо протестировать базовые концепции; ∙ когда пользователи не уверены в своих потребностях; ∙ когда требования слишком сложные; ∙ при разработке новой функции или новой серии продуктов; ∙ когда ожидаются существенные изменения, например, при изучении или исследовательской работе;
| Обзор моделей жизненного цикла разработки ПО | 31 |
Источник: studfile.net
Что такое спиральная модель разработки программного обеспечения: кому она подходит, достоинства и недостатки. Кейсы с использованием спиральной модели. Диаграмма Исикавы и цикл Деминга.
В спиральной модели разработки жизненный цикл продукта закручен в виде спирали и разделен на фазы. Прохождение каждого витка дает инкремент, то есть некий готовый функционал.
Миша Ряженка
Founder, Executive Partner
Что такое спиральная модель разработки ПО?
В спиральной (спиралевидной) модели разработки все идет по спирали: жизненный цикл продукта закручен в нее и разделен на фазы. Прохождение каждого витка дает инкремент. То есть некий готовый функционал.
Миша Ряженка
Founder, Executive Partner
Как работает спиралевидная модель?
Петли спирали — это фазы разработки ПО. В модели выделяют четыре главные фазы: Планирование. Анализ и выявления рисков. Разработка и тестирование. Оценка результата и переход к новому витку.
Миша Ряженка
Founder, Executive Partner
Оценка рисков в спиральной модели разработки
Спиральная модель справляется с рисками через создание прототипов на каждом этапе разработки. Также на каждом этапе определяют характеристики продукта, все тщательно анализируют.
Миша Ряженка
Founder, Executive Partner
Спиральная модель разработки ПО
В спиральной (спиралевидной) модели разработки все идет по спирали: жизненный цикл продукта закручен в нее и разделен на фазы. Каждый виток спирали может быть моделью водопада (waterfall) или V–образной моделью (разработка через тестирование). Разработка идеи поэтапно. Пока не завершится предыдущий этап, следующий не начнется.
Прохождение каждого витка дает инкремент. То есть некий готовый функционал.
Кстати, использовать спиральную модель начали больше 30 лет назад. И она до сих пор актуальна.
Продакт–менеджер
Долгосрочная программа
Обучение с нуля профессии «Продакт–менеджер» в IT на реальных рыночных кейсах. Передадим вам практический коммерческий опыт и подготовим к трудоустройству.
Спиральная и цикличная модели разработки ПО
Миша Ряженка
Founder, Executive Partner
Оценка рисков в спиральной модели разработки (v2)
Спиральная модель справляется с рисками через создание прототипов на каждом этапе разработки. Также на каждом этапе определяют характеристики продукта, все тщательно анализируют.
Каждая последующая фаза разработки зависит от предыдущей, основывается на ней. И в конце каждого витка спирали команда, заказчики и все заинтересованные в продукте лица решают: продолжать проект или нет.
Миша Ряженка
Founder, Executive Partner
Преимущества спиралевидной модели разработки ПО
- Позволяет добавить дополнительный функционал на любом этапе разработки, даже на последних стадиях.
- Постоянная оценка и контроль рисков делают общее видение проекта максимально ясным.
- Клиенты довольны. Так как заказчик видит разработку на ранних стадиях. Постоянно дает обратную связь. И успевает привыкнуть к системе к моменту завершения разработки.
- Проект можно разделить на несколько частей и самые рискованные реализовать на начальной стадии разработки.
- Строгий контроль над документацией проекта.
Миша Ряженка
Founder, Executive Partner
Недостатки спиральной модели разработки ПО
- Сложно в ней разобраться. Точно сложнее, чем в других моделях. Каждая итерация — это отдельная экспертиза. Управлять таким проектом нелегко.
- Дорогостоящая. И из–за этого подходит далеко не всем проектам.
- Вся завязано на анализе рисков. От этого зависит успех всего проекта и его завершение в принципе. Соответственно без опытного специалиста в этой области не обойтись.
- Сложно рассчитать время реализации проекта и даже время завершения отдельных фаз. Потому что их количество в начале разработки неизвестно.
- Есть риск застрять на начальных стадиях разработки. Совершенствовать первую версию продукта и не двигаться дальше.
- Нужно готовить большое количество документации по проекту. Так как много стадий разработки.
Миша Ряженка
Founder, Executive Partner
Кейс разработки системы «Умный дом» по спиральной модели
На первом этапе заказчик поставил задачу: сделать возможность управления чайником с телефона: вскипятить, включить режим подогрева до определенной температуры, выключить.
Команда разработки приняла идею, проанализировала подобные решения на рынке, оценила возможные риски и выработала стратегию для их разрешения. Затем с заказчиком обсудили архитектуру системы. Определились, как все будут реализовывать, перешли к разработке. Затем протестировали продукт, исправили недочеты, взяли у заказчика обратную связь. И, наконец, реализовали готовое решение.
Затем перешли к следующей задаче заказчика: реализовать управление телевизором с телефона. По сути это следующая версия того же продукта. Команда разработки действовала по той же схеме, что и с чайником. И разработала решение на базе первого продукта.
Затем перешли к следующему этапу. Заказчик захотел создать функционал для управления холодильником с телефона. Команда начала анализировать риски и выяснила, что для этого нужно встраивать в холодильник модуль wi-fi. Но производители бытовой техники не были заинтересованы в сотрудничестве, и решение выходило слишком дорогим.
То есть риски превысили потенциальную выгоду от реализации функционала. Информацию предоставили заказчику и он принял решение завершить разработку и сосредоточиться на совершенствовании, доведении до ума уже имеющихся функций по управлению чайником и телевизором.
Источник: leadstartup.ru