Модель кодирования и устранения ошибок

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

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

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

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

1. Инженерный подход
2. С учетом специфики задачи
3. Современные технологии быстрой разработки

Теперь рассмотрим непосредственно существующие модели (подклассы) и оценим их преимущества и недостатки.

Модель кодирования и устранения ошибок

Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы.
Данная модель имеет следующий алгоритм:

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

Модель также ужасно устаревшая. Характерна для 1960-1970 гг., по-этому преимуществ перед следующими моделями в нашем обзоре практически не имеет, а недостатки на лицо. Относится к первой группе моделей.

Каскадная модель жизненного цикла программного обеспечения (водопад)

Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.

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

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

Недостатки:

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

Относится к первой группе моделей.

Каскадная модель с промежуточным контролем (водоворот)

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

V модель (разработка через тестирование)

Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.

Модель на основе разработки прототипа

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

1. Прояснить не ясные требования (прототип UI)
2. Выбрать одно из ряда концептуальных решений (реализация сцинариев)
3. Проанализировать осуществимость проекта

Классификация протопипов:

1. Горизонтальные и вертикальные
2. Одноразовые и эволюционные
3. бумажные и раскадровки

Горизонтальные прототипы — моделирует исключительно UI не затрагивая логику обработки и базу данных.
Вертикальные прототипы — проверка архитектурных решений.
Одноразовые прототипы — для быстрой разработки.
Эволюционные прототипы — первое приближение эволюционной системы.

Модель принадлежит второй группе.

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

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

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

• Быстрое получение результата
• Повышение конкурентоспособности
• Изменяющиеся требования — не проблема

Недостатки:

• Отсутствие регламентации стадий

Третьей группе принадлежат такие модели как экстремальное программирование (XP), SCRUM, инкриментальная модель (RUP), но о них я бы хотел рассказать в отдельном топике.

Большое спасибо за внимание!

Software Development Life Cycle (SDLC, жизненный цикл программного обеспечения) — концепция создания информационных систем, включающая их планирование, разработку, тестирование и развертку информационных систем. Она применяется к аппаратным, программным или комбинированным ИС. С ее помощью разработчики стремятся производить высококачественные системы, соответствующие ожиданиям клиентов, в запланированные сроки и по смете.

Концепция SDLC начала формироваться в 60-х годах прошлого века в среде крупных бизнес-конгломератов, чья деятельность была основана на обработке больших данных и выполнении множества рутинных операций. Сегодня она объединяет в себе несколько гибких, итерационных и последовательных методологий, приспособленных для выполнения проектов различного масштаба и сложности.

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

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

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

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

Разработка. На этой стадии жизненного цикла осуществляется непосредственная работа по созданию и сборке продукта в соответствии с DDS. При наличии детализированного и организованного дизайна написание кода обычно не вызывает серьезных затруднений. В разработке применяются такие средства программирования, как компиляторы, интерпретаторы, отладчики и т.д. Код пишется на различных языках программирования высокого уровня — например C,  C++, Pascal, Java и PHP. Его выбор зависит от типа разрабатываемого ПО.

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

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

Модели жизненного цикла ПО

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

Условно модели разделяются на три основных категории:

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

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

Модель кодирования и устранения ошибок

Она принадлежит к числу последовательных, была популярна в 1960–1970-е годы и на данный момент считается уже устаревшей. Тем не менее она все еще распространена в обучении программистов, например в вузах. Условно она подразделяется на несколько этапов:

• постановка задачи;
• выполнение задачи;
• проверка результатов.

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

Каскадная модель (водопад)

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

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

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

Недостатки:

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

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

У «водопада» есть более совершенная версия — «водоворот». Его отличие заключается в том, что на каждом этапе присутствует обратная связь по продукту от заказчика. С одной стороны, это сокращает накопление ошибок, с другой — значительно увеличивает стоимость разработки.

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

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

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

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

Недостатки:

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

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

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

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

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

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

Недостатки:

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

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

Agile

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

• SCRUM — команда разработчиков ежедневно собирается на небольшие (не более 15 минут) встречи, а в конце отчетного периода (обычно 1–2 недель) на большом собрании отчитывается о проделанной работе;
• Kanban — рабочий процесс визуализируется с помощью виртуальной доски, на которой отражены этапы разработки, прошедшие, текущие и запланированные задачи, которые можно свободно двигать в зависимости от изменяющихся требований.

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

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

Недостатки:

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

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

Цикл
разработки программного обеспечения

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

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

1. Инженерный
   подход

2. С
   учетом специфики задачи

3. Современные
   технологии быстрой разработки

Теперь
рассмотрим непосредственно существующие
модели (подклассы) и оценим их преимущества
и недостатки.

Давайте,
более подробно рассмотрим подклассы
моделей.

Модель
кодирования и устранения ошибок

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

• Шаг
  1: постановка задачи

• Шаг
  2: создание программы

• Шаг
  3: тестирование

• Шаг
  4: анализ результата тестирования и
  возможный переход к шагу 1

Эта
модель относится к первой группе и
совсем не актуальна при профессиональной
разработке программного обеспечения.
По таким алгоритмам работали программисты
50-60 лет назад. Излишняя простота в данном
случае не позволяет конкурировать с
другими существующими моделями.
Недостатки

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

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

Алгоритм
каскадной модели

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

• Последовательное
  выполнение этапов проекта в строгом
  фиксированном порядке

• Позволяет
  оценивать качество продукта на каждом
  этапе

Недостатки:

• Отсутствие
  обратных связей между этапами

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

• Относится
  к первой группе моделей.

«Водоворот»
или каскадная модель с промежуточным
контролем

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

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

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

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

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

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

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

V
модель — разработка через тестирование

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

Модель
на основе разработки прототипа

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

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

• Прояснить
  не ясные требования (прототип UI)

• Выбрать
  одно из ряда концептуальных решений
  (реализация сцинариев)

• Проанализировать
  осуществимость проекта

Классификация
протопипов:

• Горизонтальные
  прототипы — моделирует исключительно
  UI не затрагивая логику обработки и базу
  данных.

• Вертикальные
  прототипы — проверка архитектурных
  решений.

• Одноразовые
  прототипы — для быстрой разработки.

• Эволюционные
  прототипы — первое приближение
  эволюционной системы.

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

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

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

1. Результат
   достигается в кратчайшие сроки.

2. Конкурентоспособность
   достаточно высокая.

3. При
   изменении требований, не придется
   начинать все с «нуля».

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

Отдельного
рассказа заслуживают модели экстремального
программирования (ХР), SCRUM, инкриментальная
модель (RUP). Это все модели, относятся к
третьей группе, но для их анализ будет
проведен в отдельной статье.

И
в заключении

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

Соседние файлы в папке Add

• #
• #

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

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

Понятие разработки

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

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

Жизненный цикл – это…

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

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

Основной состав

Жизненный цикл (ЖЦ) обычно включает в себя:

• подготовку;
• проектирование;
• поддержку;
• написание (непосредственное создание).

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

1. Приобретение. Так характеризуются действия заказчика, позволяющие сформировать требования и ограничения к желаемой программе. Пример – заключение договора на разработку ПОЮ анализ и аудит выполненных задач. Результатом станет получение готового продукта.
2. Поставку. Представлена мероприятиями, организованными специалистами. Работники анализируют выдвинутые клиентские требования, создают приложение, подводят итоги. После этого осуществляется решение вопросов, связанных с непосредственным программированием. Завершается проверкой (так называют тестирование) и поставкой программы.
3. Разработку. Это – комплекс мероприятий, характеризующийся написанием программного кода и формированием дизайна.
4. Эксплуатацию. Здесь начинается использование готового приложения.
5. Сопровождение. Поддержка пользователей по мере необходимости. Разработчики будут заниматься исправлением ошибок и возникающих неполадок.

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

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

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

Ключевые модели

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

Основные модели жизненного цикла программного обеспечения:

• модель кодирования и устранения ошибок;
• водопадная модель;
• разработка через тестирование;
• инкрементная модель;
• итерационная модель;
• спиральная модель;
• модель «хаоса»;
• разработка через прототипирование.

Далее каждый вариант будет рассмотрен детально. А еще – сравнение для тех или иных целей разработки.

«Водопад»

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

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

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

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

Главные фазы этой системы обычно следующие:

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

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

Плюсы и минусы

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

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

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

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

Недостатки здесь тоже есть:

1. Динамические изменения невозможны. А еще здесь трудно сформулировать четкие требования.
2. Низкая гибкость в управлении проектом.
3. Линейная структура процесса разработки при обнаружении ошибок приводит к увеличению затрат и нарушению установленных изначально сроков реализации продукта.
4. Промежуточные приложения нельзя использовать. Они не будут работать.
5. Отсутствие гибкости моделирования уникальных систем.
6. Проблемы, связанные со сборкой, обнаруживаются на завершающих этапах разработки.
7. Отсутствие гарантий качестве главного (итогового) продукта до того момента, как завершится «жизнь» проекта. Пока он не будет «собран», неизвестно, что получится в итоге.
8. Каждая фаза – это предпосылка для выполнения последующих операций. Это повышает риски для систем без аналогов. Связан соответствующий момент с отсутствием гибкого моделирования.

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

Область применения

Данный вариант сильно ограничен в области применения. Связано это с ее непосредственными недостатками. Эффективное применение cascade model обосновано, если:

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

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

Инкрементный вариант

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

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

Здесь происходит следующее:

1. Начинается работа над проектом. Определяются ключевые системные требования. Они делятся на более и менее важные.
2. Ведется проектирование системы по принципу приращений. Делается это так, чтобы полученные результаты можно было задействовать в будущем при написании приложения. Каждый инкремент – это определенная функциональность. Выпуск начинается с наиболее значимого элемента.
3. Когда основная часть проекта готова, проводится ее детализация. В это время можно уточнить требования для других фрагментов программы, которые в текущей связи требований заморожены. При необходимости к ним разрешено вернуться позже.
4. Если часть программы готова, ее можно использовать в работе. Это помогает уточнять требования для оставшихся элементов.
5. Ведется «программирование» остальных компонентов проекта.
6. Приложение совершенствуется до того момента, пока ТЗ не будет реализовано во всей своей полноте.

Если провести сравнение с «каскадом», то инкрементный подход используется в сложных и комплексных системах. Это – «программирование версиями».

Особенности

К сильным сторонам incremental process относят:

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

Недостатки:

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

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

Спиральный тип

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

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

Сильные и слабые стороны

Spiral processes имеет такие преимущества:

1. Дает возможность быстрее показать работоспособный продукт.
2. Предусматривает изменение требований при написании ПО.
3. Здесь предусматривается гибкое проектирование. Итерации тоже не запрещены.
4. Итоговый продукт получается более стабильным и надежным. Слабые места команда программистов должна определить на каждой конкретной итерации.
5. Пользователи могут провести сравнение версий и поучаствовать в непосредственной доработке проекта. Обратная связь с целевой аудиторией налажена по максимуму.

Недостатки:

1. Реализация проекта может обойтись дорого. Особенно если он имеет низкую степень риска или небольшие размеры.
2. Жизненный цикл программного обеспечения имеет усложненную структуру. Это приводит к затруднению ее применения заказчиками и менеджерами.
3. Спираль может длиться бесконечно долго.
4. Промежуточные циклы в больших количествах приводят к созданию дополнительной документации.
5. Проблематично определить цели и стадии, указывающие на готовность продукта.

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

Итеративный вариант

Виды (концепции) разработки могут быть итеративными. Этот вариант наиболее прост для заказчика, и сложен для программистов. Тут этапы жизненного цикла желаемого программного обеспечения не определены «от начала до конца». Клиент знает, что он хочет получить в конечном итоге. А вот как – дело разработчиков. Известна первоначальная идея, реализация не имеет детализации. Пример: клиент хочет выпустить собственную социальную сеть, но что там конкретно будет, как она будет выглядеть – нет.

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

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

Хотите освоить современную IT-специальность? Огромный выбор курсов по востребованным IT-направлениям есть в Otus!

За прекрасную картинку спасибо Toggl.com.

Подготовлено по материалам вебинара «Модели и методологии разработки ПО» Анастасии Кайгородовой, преподавателя факультета тестирования ПО.

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

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

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

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.

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

Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.

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

Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.

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

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

Основные модели разработки ПО

• Code and fix — модель кодирования и устранения ошибок;
• Waterfall Model — каскадная модель, или «водопад»;
• V-model — V-образная модель, разработка через тестирование;
• Incremental Model — инкрементная модель;
• Iterative Model — итеративная (или итерационная) модель;
• Spiral Model — спиральная модель;
• Chaos model — модель хаоса;
• Prototype Model — прототипная модель.

Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.

Waterfall (каскадная модель, или «водопад»)

В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.

Преимущества «водопада»

• Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты, может управлять сроками и стоимостью.
• Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до».
• Не нужно нанимать тестировщиков с серьёзной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию.

Недостатки каскадной модели

• Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить её будет стоить дорого. Тестировщики обнаружат её, когда разработчик уже написал код, а технические писатели — документацию.
• Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит.
• Разработчики пишут много технической документации, что задерживает работы. Чем обширнее документация у проекта, тем больше изменений нужно вносить и дольше их согласовывать.

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

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

V-образная модель (разработка через тестирование)

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

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

• Количество ошибок в архитектуре ПО сводится к минимуму.

Недостатки V-образной модели

• Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».

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

Incremental Model (инкрементная модель)

Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.

1. Заказчик решил, что хочет запустить соцсеть, и написал подробное техническое задание. Программисты предложили реализовать основные функции — страницу с личной информацией и чат. А затем протестировать на пользователях, «взлетит или нет».
2. Команда разработки показывает продукт заказчику и выпускает его на рынок. Если и заказчику, и пользователям социальная сеть нравится, работа над ней продолжается, но уже по частям.
3. Программисты параллельно создают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и других действий, согласованных с заказчиком. Инкремент за инкрементом они совершенствуют продукт, приближаясь к описанному в техническом задании.

Преимущества инкрементной модели

• Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок — и по итогам обратной связи решает, продолжать ли разработку.
• Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен.
• Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.

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

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

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

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

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

Рассмотрим на примере создания мессенджера, как эта модель работает.

1. Заказчик решил, что хочет создать мессенджер. Разработчики сделали приложение, в котором можно добавить друга и запустить чат на двоих.
2. Мессенджер «выкатили» в магазин приложений, пользователи начали его скачивать и активно использовать. Заказчик понял, что продукт пользуется популярностью, и решил его доработать.
3. Программисты добавили в мессенджер возможность просмотра видео, загрузки фотографий, записи аудиосообщений. Они постепенно улучшают функциональность приложения, адаптируют его к требованиям рынка.

Преимущества итеративной модели

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

Недостатки итеративной модели

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

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

Spiral Model (спиральная модель)

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

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом». 

1. Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут её реализовывать, разработали, протестировали и «выкатили» конечный продукт.
2. Заказчик оценил результат и риски: насколько нужна пользователям следующая версия продукта — уже с управлением телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты действовали по каскадной модели и представили заказчику более сложный продукт, разработанный на базе первого.
3. Заказчик подумал, что пора создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, да и производители не заинтересованы в сотрудничестве по этому вопросу. Следовательно, риски превышают потенциальную выгоду. На основе полученных данных заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность, чтобы со временем понять, как развивать систему «Умный дом».

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

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

• Большое внимание уделяется проработке рисков.

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

• Есть риск застрять на начальном этапе — бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.
• Разработка длится долго и стоит дорого.

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

Что такое Agile?

Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:

• экстремальное программирование (Extreme Programming, XP);
• бережливую разработку программного обеспечения (Lean);
• фреймворк для управления проектами Scrum;
• разработку, управляемую функциональностью (Feature-driven development, FDD);
• разработку через тестирование (Test-driven development, TDD);
• методологию «чистой комнаты» (Cleanroom Software Engineering);
• итеративно-инкрементальный метод разработки (OpenUP);
• методологию разработки Microsoft Solutions Framework (MSF);
• метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
• метод управления разработкой Kanban.

Различия между Agile и традиционным подходом к разработке мы свели в таблице:

Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban. 

Kanban

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

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

Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!