Жизненный цикл программного обеспечения (ПО) – период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.
Жизненный цикл ПО представляет совокупность итерационных процедур, связанных с последовательным изменением состояния ПО.
Разработка – это только один из процессов, связанных с программной системой. Разработка также имеет свой жизненный цикл.
Жизненный цикл разработки ПО – период времени, начинающийся с формирования общего представления о разрабатываемой системе и его формализации в виде требований верхнего уровня и завершаемый вводом системы в эксплуатацию. Этап сопровождения программной системы также часто включают в жизненный цикл разработки ПО.
Модели жизненного цикла разработки
Коллективная разработка, в отличие от индивидуальной, требует четкого планирования работ и их распределения во время создания программной системы. Один из способов организации работ состоит в разбиении процесса разработки на отдельные последовательные стадии, после полного прохождения которых получается конечный продукт или его часть. Такие стадии и образуют жизненный цикл разработки ПО.
Просто о SDLC (Жизненный цикл разработки ПО)
Любой этап жизненного цикла имеет четко определенные критерии начала и окончания. Состав этапов жизненного цикла, а также критерии, определяющие последовательность этапов жизненного цикла, задаются коллективом разработчиков и/или заказчиком. В настоящее время существует несколько основных моделей жизненного цикла, которые могут быть адаптированы под реальную разработку.
Модель жизненного цикла разработки ПО – структура, систематизирующая различные виды проектной деятельности, их взаимодействие и последовательность в процессе разработки ПО. Выбор той или иной модели зависит от масштаба и сложности проекта, предметной области, доступных ресурсов, планируемой частоты внесения изменений в систему, сроков разработки и других факторов.
Выбор модели жизненного цикла разработки ПО серьезно влияет на процесс тестирования, определяя выбор стратегии, расписание, необходимые ресурсы и т.д.
Классический жизненный цикл разработки ПО
Старейшей моделью процесса разработки ПО является классический жизненный цикл, который также называют каскадной или водопадноймоделью, подчеркивая, что разработка рассматривается как последовательность этапов, причем переход на следующий, иерархически нижний этап, происходит только после полного завершения работ на предыдущем этапе (рис. 1).
Рис. 1 Классический жизненный цикл разработки ПО
Подразумевается, что разработка начинается с заключения контракта с заказчиком (подготовка) и проходит через планирование, моделирование, конструирование и развертывание.
Подготовка обеспечивает активное взаимодействие с потенциальным заказчиком. Помимо оформления контракта, здесь собираются и формируются требования, определяющие характеристики и функции будущей программной системы. В процессе сбора требований необходим интенсивный диалог с заказчиком. Фактически эти требования определяют полное задание на разработку.
SDLС — Жизненный цикл разработки программного обеспечения. Подробный разбор этапов разработки.
На этапе планирования проекта определяется объем будущих работ и их риск, необходимые трудозатраты, формируются рабочие задачи и расписание (план-график работ).
Моделирование включает в себя два действия – анализ требований и проектирование. Результаты этих действий – модели – обычно записываются на графическом языке моделирования, т.е. языке схем.
В ходе анализа требований происходит обработка набора требований к ПО, сформированных на этапе подготовки. Уточняются и детализируются функции, характеристики и интерфейс ПО. Все текстовые определения и модели документируются в спецификации анализа.
Проектирование состоит в создании представлений: архитектуры ПО; структурной и поведенческой организации частей архитектуры; входного и выходного интерфейса частей архитектуры (входных и выходных форм данных).
Архитектура ПО определяет организационную структуру программной системы, задает ее разбиение на части, связи между этими частями, механизмы взаимодействия и основные руководящие принципы для детализации дальнейшего проектирования системы.
Например, решение создавать программный продукт в виде системы, имеющей два уровня, каждый из которых содержит свои подсистемы, определенным образом сообщающиеся между собой, относится к архитектуре.
Исходные данные для проектирования содержатся в спецификации анализа. По сути, в ходе проектирования выполняется трансляция требований к ПО во множество проектных представлений.
Конструирование включает в себя кодирование и тестирование.
Кодирование, называемое также программированием или реализацией, состоит в переводе результатов проектирования в текст на языке программирования.
Тестирование – проверка соответствия программного кода требованиям, определенным на предыдущих этапах, включающая выполнение программы для выявления ошибок в функциях, логике и форме реализации программного продукта. Если ошибки выявлены, то запускается отладка, цель которой – устранить ошибки.
Развертывание включает в себя поставку разработанного продукта заказчику и сопровождение процесса эксплуатации этого продукта.
Сопровождение –это внесение изменений в эксплуатируемое ПО. Цели изменений: исправление ошибок; адаптация к изменениям внешней для ПО среды; усовершенствование ПО согласно требованиям заказчика.
Адаптация требуется, например, если заказчик хочет использовать продукт с другой операционной системой, а усовершенствование состоит или в расширении функциональности продукта, или в изменении каких-то характеристик (например, в ускорении реакции на запросы пользователей).
Сопровождение ПО заключается в повторном применении одного (или нескольких) из предшествующих шагов (этапов) жизненного цикла к существующему ПО, но не в разработке нового ПО. Такая возможность показана на рис. 1 стрелками обратных связей.
Достоинства классического жизненного цикла: дает план и временной график по всем этапам проекта, упорядочивает ход разработки.
Недостатки классического жизненного цикла:
– реальные проекты часто требуют отклонения от стандартной последовательности шагов;
– цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);
– результаты проекта доступны заказчику только в конце работы;
– участие пользователей ПО либо не предусмотрено вообще, либо предусмотрено лишь косвенно на стадии однократного сбора требований.
Естественно, что в случае достаточно больших систем такой подход себя не оправдывает. Работа на каждом этапе занимает значительное время, а внесение изменений в первичные документы либо невозможно, либо вызывает лавинообразные изменения на всех других этапах.
Как правило, используется модификация каскадной модели, допускающая возврат на любой из ранее выполненных этапов. При этом фактически возникает дополнительная процедура принятия решения.
Если тест-кейсы обнаружили несоответствие реализации требованиям, то причина может находиться: в неправильном тесте; в ошибке кодирования (реализации); в неверной архитектуре системы; в некорректности требований к ПО и т.д. Все эти случаи требуют анализа, для того чтобы принять решение о том, на какой этап жизненного цикла надо возвратиться для устранения обнаруженного несоответствия.
Часть недостатков каскадной модели устраняет V-образный жизненный цикл – модель жизненного цикла, содержащая процессы двух видов: основные процессы разработки, аналогичные процессам каскадной модели, и процессы верификации, представляющие цепь обратной связи по отношению к основным процессам.
Таким образом, в конце каждого этапа жизненного цикла разработки, а зачастую и в процессе выполнения этапа, осуществляется проверка взаимной корректности требований различных уровней. Данная модель позволяет более оперативно проверять корректность разработки, однако, как и в каскадной модели, предполагается, что на каждом этапе разрабатываются документы, описывающие поведение всей системы в целом.
Макетирование
Достаточно часто заказчик не может сформулировать подробные требования по вводу, обработке или выводу данных для будущего программного продукта. С другой стороны, разработчик может сомневаться в приспосабливаемости продукта под операционную систему, форме диалога с пользователем или в эффективности реализуемого алгоритма. В этих случаях целесообразно использовать макетирование.
Макетирование (прототипирование) – это процесс создания модели требуемого программного продукта. Основная цель макетирования – снять неопределенности в требованиях заказчика.
Модель может принимать одну из трех форм:
1) бумажный макет или макет, выполненный на компьютере (изображает человеко-машинный диалог);
2) работающий макет (выполняет некоторую часть требуемых функций);
3) существующая программа (характеристики которой затем должны быть улучшены).
Как показано на рис. 2, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.
Рис. 2 Макетирование
Последовательность действий при макетировании представлена на рис. 3 в виде диаграммы деятельности языка UML.
Макетирование начинается со сбора и уточнения требований к ПО. Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить.
Затем выполняется быстрое проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю. Быстрое проектирование приводит к построению макета. Макет оценивается заказчиком и используется для уточнения требований к ПО.
Рис. 3 Последовательность действий при макетировании
Итерации повторяются до тех пор, пока макет не выявит все требования заказчика и, тем самым, не даст возможность разработчику понять, что должно быть сделано.
Достоинство макетирования: обеспечивает определение полных требований к ПО.
Недостатки макетирования:
– заказчик, видя работающую версию системы, может потребовать быстро преобразовать ее в рабочий продукт, но при этом остаются нерешенными вопросы качества и удобства сопровождения;
– для быстрого получения работающего макета разработчик часто идет на определенные компромиссы (например, используя не самый подходящий язык программирования или неэффективный алгоритм), и, спустя некоторое время, может не исправить это в рабочем продукте, забыв о причинах, по которым выбранные изначально средства не подходят.
Спиральная модель
Спиральная модель – это классический пример применения эволюционной стратегии разработки. При использовании эволюционной стратегии система строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий.
Спиральная модель базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих моделях.
Как показано на рис. 4, модель определяет четыре действия, представляемые четырьмя квадрантами спирали: подготовка – сбор требований и ограничений; планирование – формирование плана проекта и анализ риска; моделирование и конструирование – подготовка моделей и реализация продукта следующего уровня; развертывание – оценка заказчиком текущей версии продукта.
Рис. 4 Спиральная модель: начальный сбор требований проекта (1); та же работа, но на основе рекомендаций заказчика (2); планирование проекта и анализ риска на основе начальных требований (3); планирование и анализ риска на основе реакции заказчика (4); переход к комплексной системе (5); построение начального макета системы (6); построение версии системы следующего уровня (7); оценивание заказчиком (8).
В спиральной модели разработка системы происходит повторяющимися этапами – витками спирали – и отображается (рис. 4) движением по разворачивающейся спирали (по часовой стрелке), причем проект стартует в первом квадранте.
В конце каждого витка получается законченная версия системы, реализующая некоторый набор функций. Затем она предъявляется пользователю, на следующий виток переносится вся документация, разработанная на предыдущем витке, и процесс повторяется.
С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. Таким образом, система разрабатывается постепенно, проходя постоянные согласования с заказчиком. На каждом витке спирали функциональность системы расширяется, постепенно дорастая до полной.
В каждом витке по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен. В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей версии системы.
Достоинства спиральной модели:
– наиболее реально (в виде эволюции) отображает разработку ПО;
– позволяет явно учитывать риск на каждом витке эволюции разработки;
– включает возможность оценки системы в итерационную структуру разработки;
Недостатки спиральной модели:
– повышенные требования к заказчику;
– трудности контроля и управления временем разработки.
С точки зрения тестирования и управления качеством повышенное внимание рискам является ощутимым преимуществом при использовании спиральной модели для разработки концептуальных проектов, в которых требования естественным образом являются сложными и нестабильными (могут многократно меняться по ходу выполнения проекта).
Источник: megalektsii.ru
Жизненный цикл разработки ПО
Перед тем, как начать разработку ПО, необходимо понимать, какие этапы нужно пройти перед началом работы, с какими придется столкнуться во время самой работы и какие ждут после ее завершения.
Сергей Ахметов, СТО TalentTech, составил подробный чек-лист о том, как собрать команду профессионалов и какие шаги нужно пройти, чтобы создать продукт мечты.
Этап разработки. Где взять заказчика?
Когда человек основывает компанию, у него уже должны быть гипотезы о том, какие боли и задачи потенциального клиента его продукт призван решить. Либо у него есть ряд знакомых, которые четко говорят: «Если ты предоставишь мне такую услугу, я тебе готов заплатить». Это могут быть первые заказчики на момент рождения компании.
Когда у компании уже есть продукт, важно настроить процессы в маркетинге и продажах, чтобы достучаться до потенциального клиента, привести лиды – предварительно заинтересованных клиентов, обработать их и конвертировать в заказ. Следующий этап не менее важный – внедрение продукта внутри компании клиента, так как мы говорим о рынке B2B.
Hello, production: почему первый релиз стоит сделать как можно раньше
И последнее — «управление счастьем» клиента, туда входит и техническая поддержка, и обновления, и, возможно, удовлетворение следующих болей продажи дополнительных услуг, то есть то, что вы уже как работаете с клиентом и его уже удержать, и получать его деньги все дольше и дольше.
Составление техзадания. Как не перепутать роли при выполнении задач?
В любом проекте есть две роли product- и project- менеджер, на раннем этапе их может исполнять один человек.
Product-менеджер отвечает за общее развитие продукта и его видение, а также стремится к тому, чтобы продукт удовлетворял не только задачам одного конкретного заказчика, а решал целый ряд схожих проблем, и его можно было бы впоследствии масштабировать, продавать многим другим клиентам.
Project-менеджер ведёт проект у конкретного заказчика и делает так, чтобы ваш продукт максимально удовлетворял уникальную потребность конкретного клиента. Его работа начинается с предпродажи, он управляет замыслом проекта, составлением ТЗ, ведёт шаг за шагом проектную работу и отвечает за конечное внедрение.
В зависимости от размера проекта могут появиться роли бизнес-аналитика и системного аналитика. Это люди, которые детально изучают проект, который необходимо реализовать, и прорабатывают документацию, с которой работают разработчики.
«Управление счастьем клиента». Способы организовать такой процесс
На этом этапе есть несколько уровней предложения.
Первый — стандартизированный пакет услуг, в рамках которого вы предоставляете SLA (Service Level Agreement), то есть соглашение об уровне обслуживания. В нем важно отметить, насколько быстро вы реагируете на запрос клиента, какой объем услуг можете оказать ему, что в этот перечень услуг входит. Обычно это чётко регламентировано и описано.
Второй вариант: индивидуальные условия: в зависимости от потребности клиента компания может предоставить ему отдельного менеджера, дополнительный пул часов или оказанных работ, набор скидок при большом количестве заказов. В этом случае условия кастомизируются абсолютно индивидуально и, как правило, нужно назначить менеджера по работе с ключевыми заказчиками, который будет вести процесс работы с конкретным клиентом.
Исключаем ошибки при разработке
- Самое первое и главное — не ошибиться в людях при найме. В разработке ПО единственно важный, стоящий и приносящий вам пользу актив — сотрудники. И на первых порах главное правильно их подобрать. Способы избежать ошибок в выборе команды:
- На первых этапах подбора нужно ответить себе честно на вопрос, обладаете ли вы необходимыми компетенциями, чтобы оценить профессионализм кандидата? Можете ли вы положиться на рекомендации знакомых, обладают ли они компетенциями в вашей сфере бизнеса? При подборе нужно разделять эмоции и факты – нанять обаятельного, но некомпетентного сотрудника будет ошибкой.
- Сделайте как можно короче цикл обратной связи в рабочих процессах. Не надо ждать месяц, чтобы определиться, подходит ли сотрудник вашей компании.
- Если у вас есть замечания к работе сотрудника и вы понимаете, что ожидали от него других результатов, сообщите ему об этом как можно скорее.
- Важно, чтобы сотрудники умели принимать обратную связь и реагировать на нее. Отсутствие этого дает понять, что в будущем с этим человеком не получится комфортной и продуктивной работы.
2. Вторая ошибка при разработке — недостаточное внимание развитию сотрудников, их личному росту, вовлечённости, эмоциональному состоянию, производительности. Так как это ваш главный инструмент, нужно очень активно заботиться о том, чтобы он был в наиболее комфортном и производительном состоянии. В работе с адаптацией сотрудников и вовлечённостью помогают технологии: например, быстрые пульс-опросы позволяют понять настроение команды, выявить «боли» и провести аналитику, чтобы исправить процессы и повысить эффективность работы.
3. Третья ошибка — продуктовая. Есть риск сделать продукт, который не полностью отвечает потребностям вашего клиента. Здесь поможет гибкий подход и итеративность — регулярный промежуточный анализ сделанного, правки в процессе, чтобы команда на каждом этапе была «на одной волне» с идеями заказчика и четко понимала, какую цель преследует.
4. Следующая ошибка — неверные технические решения и накопление технического долга. Это могут быть решения, прекрасно функционирующие сейчас, но мешающие развитию в будущем. Например, нужно отправить клиенту при регистрации письмо, но текст записан в программный код и внести изменения в нем может только программист.
Когда вы разрабатываете ПО, всегда есть выбор — сделать быстро или качественно, чтобы это в будущем не принесло проблем. Как правило, выбирается компромисс, и как бы вы не вели разработку, технический долг накапливается. Важно управлять этим процессом и вовремя ликвидировать неточности. Если об этих нюансах забыть, то через несколько лет компания может стать недееспособной.
5. Следующая возможная ошибка — игнорирование вопросов по управлению качеством. Качество — это то, что заставляет клиентов возвращаться к вам снова и снова. Недостаток внимания в этом вопросе обернется трудозатратами и потерями денег в будущем. Например, вы не написали тесты в коде, что сэкономило условный час времени. Через месяц, внося доработки, вы потратите день, чтобы убедиться, все ли корректно работает.
Финальный этап. Соблюдаем этапы разработки правильно
Во время разработки есть три источника задач. Первая входная точка — product-менеджеры, которые изучают клиентов, проводят различные эксперименты, формируют видение развития продуктов. После этого они превращают это видение в последовательность шагов для создания продукта — роадмап.
Второй источник — клиенты и их доработки. За этот этап отвечают project-менеджеры, они превращают желания заказчика в ТЗ.
Третья волна задач исходит от отдела разработки. Разработчики понимают, какой архитектурой или системами ответить на вызовы, которые ставят менеджеры и клиенты.
Три основных класса заданий сначала попадают в бэк-лог — общее хранилище всех задач. Бэк-лог анализируют product-менеджеры и project-менеджеры, выбирают самое важное и запускают в работу. Чтобы понять, какие задачи из бэк-лога нужно взять, команды договариваются о целях спринта. Этот процесс выглядит, как торг, так как учитывается множество мнений. Но никакого другого волшебного пути приоритизировать задачи не существует.
После этого происходит сам спринт — разработка функционала, тестирование, проверка качества, затем релиз и демонстрация продукта клиентам и другим командам.
В качестве примера могу привести разработку продукта TalentTech.Обучение. Началось все с идеи: в процессе создания других продуктов мы поняли, что решений для быстрого выявления слабых сторон сотрудников и индивидуального обучения не так много, а комплексных — вообще нет. Затем, пообщавшись с потенциальными представителями ЦА продукта, выявили ключевые проблемы:
- Вовлечённость в образование. «Заказали лучшего тренера, организовали вебинар, но из 5 тысяч сотрудников пришли только 100».
- Скорость обучения. «Надо запустить продукт через неделю, а закончить через месяц».
- Управление обучением. «Хотим коррелировать образование с компетенциями, понимать, кому из сотрудников какой контент нужен».
- Аналитика по обучению. «Мы провели его и что дальше? Какой результат — непонятно».
- Контент. «Не знаем, где брать качественные и актуальные знания».
Проанализировав нужды ЦА, мы добавили вовлекающие механики и геймификацию, договорились с партнерами из университета «Нетология» о предоставлении контента под наше ТЗ.
Затем договорились о пилоте с одной металлургической компанией и только на этом этапе запустили разработку, когда уже был конкретный клиент с запросом и финансами. На старте разработки лучше обговорить с клиентом метрики успеха, чтобы понимать, каких результатов надо достигнуть.
Как построить продукт, который будет нужен рынку
В первой версии продукта сделали приложение с параметрами под нужды конкретного клиента, а для будущих потенциальных заказчиков добавили возможность кастомизации. Важно сразу проанализировать рынок и понять, какие доработки будут пользоваться спросом. Помочь здесь может количественное или качественное исследование целевой аудитории.
После запуска продукта нельзя останавливаться: поддерживайте работу, собирайте фидбек и оптимизируйте функционал, в зависимости от полученной обратной связи. Таким образом, жизненный цикл ПО является довольно трудоемким процессом, который необходимо контролировать и анализировать на всех этапах разработки. Главный ваш ресурс — люди. Именно от них зависит судьба продукта — его создание, разработка и последующая долгая жизнь.
Источник: tproger.ru
Жизненный цикл разработки программного обеспечения
Жизненный цикл разработки программного обеспечения, для краткости SDLC, представляет собой четко определенную, структурированную последовательность этапов разработки программного обеспечения для разработки предполагаемого программного продукта.
Деятельность SDLC
SDLC предлагает ряд шагов, которые необходимо выполнить для эффективной разработки и разработки программного продукта. Каркас SDLC включает в себя следующие этапы:
связь
Это первый шаг, когда пользователь инициирует запрос на желаемый программный продукт. Он связывается с поставщиком услуг и пытается договориться об условиях. Он подает свой запрос в организацию, предоставляющую услуги, в письменном виде.
Сбор требований
Этот шаг вперед команда разработчиков программного обеспечения работает над продолжением проекта. Команда проводит дискуссии с различными заинтересованными сторонами из проблемной области и старается предоставить как можно больше информации об их требованиях. Требования рассматриваются и разделяются на пользовательские требования, системные требования и функциональные требования. Требования собраны с использованием ряда методов, как указано –
- изучение существующей или устаревшей системы и программного обеспечения,
- проведение опросов пользователей и разработчиков,
- ссылаясь на базу данных или
- Сбор ответов из анкет.
Технико-экономическое обоснование
После сбора требований команда разрабатывает примерный план процесса разработки программного обеспечения. На этом этапе команда анализирует, можно ли создать программное обеспечение для удовлетворения всех требований пользователя и существует ли вероятность того, что программное обеспечение больше не будет полезным. Выясняется, является ли проект финансово, практически и технологически осуществимым для организации. Существует множество доступных алгоритмов, которые помогают разработчикам сделать вывод о целесообразности программного проекта.
Системный анализ
На этом этапе разработчики решают план своего плана и стараются найти лучшую модель программного обеспечения, подходящую для проекта. Системный анализ включает в себя понимание ограничений программного продукта, проблем, связанных с системой обучения, или изменений, которые необходимо сделать в существующих системах, заранее, выявление и учет воздействия проекта на организацию и персонал и т. Д. Команда проекта анализирует масштаб проекта и планирует график и ресурсы соответственно.
Разработка программного обеспечения
Следующим шагом является полное знание требований и анализа на столе и разработка программного продукта. Входные данные от пользователей и информация, собранная на этапе сбора требований, являются входными данными этого этапа. Результат этого шага представлен в виде двух проектов; логический дизайн и физический дизайн. Инженеры производят метаданные и словари данных, логические диаграммы, диаграммы потоков данных и в некоторых случаях псевдокоды.
кодирование
Этот шаг также известен как этап программирования. Реализация разработки программного обеспечения начинается с написания программного кода на подходящем языке программирования и эффективной разработки безошибочных исполняемых программ.
тестирование
По оценкам, 50% всего процесса разработки программного обеспечения должно быть проверено. Ошибки могут испортить программное обеспечение с критического уровня до его удаления. Тестирование программного обеспечения выполняется разработчиками во время кодирования, а тщательное тестирование проводится экспертами на разных уровнях кода, таких как тестирование модулей, тестирование программ, тестирование продукта, внутреннее тестирование и тестирование продукта на стороне пользователя. Раннее обнаружение ошибок и их устранение – ключ к надежному программному обеспечению.
интеграция
Может потребоваться интеграция программного обеспечения с библиотеками, базами данных и другими программами. Этот этап SDLC связан с интеграцией программного обеспечения с объектами внешнего мира.
Реализация
Это означает установку программного обеспечения на компьютерах пользователей. Иногда программное обеспечение нуждается в настройках после установки на стороне пользователя. Программное обеспечение тестируется на мобильность и адаптивность, а проблемы, связанные с интеграцией, решаются в ходе реализации.
Эксплуатация и техническое обслуживание
Этот этап подтверждает работу программного обеспечения с точки зрения большей эффективности и меньшего количества ошибок. При необходимости пользователи проходят обучение или получают помощь по документации о том, как работать с программным обеспечением и как его поддерживать. Программное обеспечение поддерживается своевременно путем обновления кода в соответствии с изменениями, происходящими в пользовательской среде или технологии. Эта фаза может столкнуться с проблемами из-за скрытых ошибок и реальных неопознанных проблем.
диспозиция
С течением времени программное обеспечение может ухудшиться в плане производительности. Это может полностью устареть или может потребовать интенсивного обновления. Следовательно возникает насущная необходимость устранить основную часть системы. Этот этап включает в себя архивирование данных и необходимых программных компонентов, закрытие системы, планирование действий по утилизации и завершение работы системы в соответствующее время окончания системы.
Парадигма разработки программного обеспечения
Парадигма разработки программного обеспечения помогает разработчику выбрать стратегию разработки программного обеспечения. Парадигма разработки программного обеспечения имеет свой собственный набор инструментов, методов и процедур, которые четко выражены и определяют жизненный цикл разработки программного обеспечения. Несколько парадигм разработки программного обеспечения или моделей процессов определены следующим образом:
Модель водопада
Модель «Водопад» – самая простая модель парадигмы разработки программного обеспечения. В нем говорится, что все фазы SDLC будут функционировать один за другим линейно. То есть, когда первая фаза закончена, тогда только вторая фаза начнется и так далее.
Эта модель предполагает, что все выполнено и выполнено идеально, как и планировалось на предыдущем этапе, и нет необходимости думать о прошлых проблемах, которые могут возникнуть на следующем этапе. Эта модель не работает гладко, если на предыдущем шаге остались некоторые проблемы. Последовательный характер модели не позволяет нам вернуться назад и отменить или повторить наши действия.
Эта модель лучше всего подходит, когда разработчики уже проектировали и разрабатывали подобное программное обеспечение в прошлом и знают все его области.
Итерационная модель
Эта модель ведет процесс разработки программного обеспечения в итерациях. Он проектирует процесс разработки циклически, повторяя каждый шаг после каждого цикла процесса SDLC.
Программное обеспечение сначала разрабатывается в очень небольших масштабах, и выполняются все этапы, которые принимаются во внимание. Затем на каждой следующей итерации все больше функций и модулей разрабатываются, кодируются, тестируются и добавляются в программное обеспечение. Каждый цикл производит программное обеспечение, которое само по себе полно и имеет больше возможностей и возможностей, чем в предыдущем.
После каждой итерации управленческая команда может выполнить работу по управлению рисками и подготовиться к следующей итерации. Поскольку цикл включает в себя небольшую часть всего процесса разработки программного обеспечения, легче управлять процессом разработки, но он потребляет больше ресурсов.
Спиральная модель
Спиральная модель представляет собой комбинацию итерационной модели и модели SDLC. Это может выглядеть так, как будто вы выбираете одну модель SDLC и комбинируете ее с циклическим процессом (итерационная модель).
Эта модель учитывает риск, который часто остается незамеченным большинством других моделей. Модель начинается с определения целей и ограничений программного обеспечения в начале одной итерации. Следующим этапом является создание прототипа программного обеспечения. Это включает в себя анализ рисков.
Затем для построения программного обеспечения используется одна стандартная модель SDLC. На четвертом этапе готовится план следующей итерации.
V – модель
Основным недостатком модели водопада является то, что мы переходим к следующему этапу только тогда, когда предыдущий завершен, и не было возможности вернуться назад, если что-то будет найдено неправильно на более поздних этапах. V-модель предоставляет средства тестирования программного обеспечения на каждом этапе в обратном порядке.
На каждом этапе создаются планы тестирования и тестовые наборы для проверки и валидации продукта в соответствии с требованиями этого этапа. Например, на этапе сбора требований группа тестирования подготавливает все контрольные примеры в соответствии с требованиями. Позже, когда продукт будет разработан и готов к тестированию, контрольные примеры этого этапа проверяют программное обеспечение на соответствие требованиям на данном этапе.
Это позволяет и проверке, и проверке идти параллельно. Эта модель также известна как модель верификации и валидации.
Модель большого взрыва
Эта модель является самой простой моделью по форме. Это требует мало планирования, много программирования и много средств. Эта модель концептуализирована вокруг большого взрыва вселенной. Как говорят ученые, после большого взрыва множество галактик, планет и звезд эволюционировали как событие. Аналогично, если мы соберем много программ и средств, вы сможете получить лучший программный продукт.
Для этой модели требуется очень небольшое количество планирования. Это не следует ни за каким процессом, или время от времени клиент не уверен в требованиях и будущих потребностях. Таким образом, входные требования являются произвольными.
Эта модель не подходит для больших программных проектов, но хороша для обучения и экспериментов.
Для подробного изучения SDLC и его различных моделей, нажмите здесь.
Источник: coderlessons.com