Какие возвраты невозможны при разработке по водопадной модели

Обновлено: 30.06.2024

Разработка программного обеспечения не похожа на традиционные инженерные науки. Методология — это то, что используется разработчиками, чтобы разбить работу на управляемые прогрессивные этапы, где каждый из них может быть проверен для обеспечения качества. Команды работают вместе с заказчиком над созданием готового программного продукта при помощи одной из методологий разработки программного обеспечения. Наиболее популярными из них считают спиральную, водопадную, или каскадную модель (Waterfall); RAD, или быструю разработку приложений; Agile Model, или гибкую и итеративную, или итерационную модель. Существуют и другие варианты, но в этой статье рассмотрим только водопадную, или каскадную, модель жизненного цикла проекта, а также исследуем ее преимущества и недостатки. Сразу же поясним, что она представляет собой последовательность определенных шагов, и ее особенность в том, что новый этап невозможен, пока предыдущий не был завершен.

История возникновения водопадной модели

Вам будет интересно: Корректирующее действие - это. Определение, особенности и принципы

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

Вам будет интересно: Ситуационное руководство: описание модели, стили, уровни развития сотрудников

Люди спорят

Водопадная модель разработки существует уже более сорока лет. Она была впервые описана в 1970 году в статье У. Ройса как одна из самых первых официальных моделей для процесса разработки. Она описывалась как неэффективная для крупных проектов по разработке программного обеспечения, но никто не запрещал использовать ее для небольших. Почти полвека спустя после того, как она была открыта, эта методика все еще имеет значение в современном деловом мире. Ее называют устаревшей моделью и относятся с некоторым пренебрежением из-за устаревания традиционного проектного подхода к управлению. Но Waterfall является полезным и предсказуемым подходом, если требования фиксированы, хорошо документированы и ясны, если технология понятна и когда реализация проекта не занимает много времени. В этом случае каскадная модель жизненного цикла программного обеспечения может обеспечить более предсказуемый конечный результат для определенного бюджета, сроков и объема работы.

Что такое водопадная модель разработки?

Вам будет интересно: Теория и шкала Ренсиса Лайкерта

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

преимущества каскадной модели жизненного цикла

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

Описание каскадной модели

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

преимущества каскадной модели жизненного цикла

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

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

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

Плюсы и минусы водопадной модели

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

недостатки каскадной модели жизненного цикла

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

Этап обсуждения требований

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

каскадная модель жизненного цикла ис

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

Недостатки каскадной модели жизненного цикла

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

Отсутствие гибкости в каскадной модели

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

каскадная модель жизненного цикла используется

Корректировки, вызванные бизнес-планами или влиянием рынка, возможно, не были приняты во внимание при планировании. Также реализация проектов может занять больше времени по сравнению с использованием итерационной методологии, такой как Agile.

Важные моменты при использовании водопадной методологии

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

каскадная модель жизненного цикла информационной системы

Для сравнения, в Agile development клиент может увидеть фрагменты рабочего кода, которые были созданы в процессе работы над проектом. В отличие от Scrum, который делит проекты на отдельные спринты, Waterfall всегда фокусируется на конечной цели. Если у вашей команды есть конкретная цель с четкой конечной датой, Waterfall устранит риск не уложиться в срок, когда вы будете работать над ней. Исходя из этих плюсов и минусов, разработка Waterfall обычно рекомендуется для проектов, которые, скорее всего, не изменятся либо нуждаются в новых разработках в течение жизненного цикла проекта.

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

Под программным обеспечением понимается совокупность программ, выполняемых вычислительной системой. Если говорить немного более развёрнуто, то программное обеспечение – это совокупность специальных программ, облегчающих процесс подготовки задач к выполнению на ЭВМ и организующих прохождение их через машину, а также процедур, описаний, инструкций и правил вместе со всей связанной с этими компонентами документацией, используемых при эксплуатации вычислительной системы.[1]

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

1) технология проектирования программ;

2) методы тестирования программ;

3) методы доказательства правильности программ;

4) анализ качества работы программ;

5) документирование программ;

6) разработка и использование программных средств, облегчающих процесс проектирования программного обеспечения, и многое другое.[2]

Назначений у программного обеспечения несколько. Среди них:

1) обеспечение работоспособности компьютера;

2) облегчение взаимодействия пользователя с компьютером;

3) сокращение цикла от постановки задачи до получения результата;

4) повышение эффективности использования ресурсов компьютера.

Программное обеспечение позволяет:

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

2) повысить производительность и качество труда пользователя;

3) адаптировать программы пользователя к ресурсам конкретной вычислительной системы;

4) расширить ПО вычислительной системы.

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

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

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

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

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

Водопадная (каскадная) модель.

Модель водопада (каскадная модель) была предложена в 1970 году Уинстоном Ройсом и предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке.

В оригинальной модели водопада Ройса, следующие фазы шли в таком порядке:

1. Определение требований.


Рисунок 1. – Этапы каскадной модели.

Тем самым, модель водопада подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит. [6]

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

Недостатками водопадной модели являются:

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

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

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

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

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

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

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

Таковы мотивы классической итерационной модели жизненного цикла:


Рисунок 2. – Этапы итерационной модели.

Стрелки, идущие вверх, обозначают возвраты к предыдущим этапам, квалифицируемые как требование повторить этап для исправления обнаруженной ошибки. В связи c этим может показаться странным переход от этапа Эксплуатация и сопровождение к этапу Тестирование и отладка. Дело в том, что рекламации, предъявляемые в ходе эксплуатации системы, часто даются в такой форме, что нуждаются в перепроверке. Чтобы понять, о каких ошибках идет речь в рекламации, разработчикам полезно предварительно воспроизвести пользовательскую ситуацию у себя, т.е. выполнить действия, которые обычно относят к тестированию. [8]

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

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

2. Функциональные и архитектурные прототипы, непригодные для промышленной эксплуатации, но позволяющие оценить функциональный дизайн, пользовательский интерфейс, производительность и т.д.[9]

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

Итеративная модель обладает рядом преимуществ по сравнению с водопадной:

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

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

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

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

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

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

Каждый виток имеет следующую структуру (секторы):

1) определение целей, ограничений и альтернатив проекта;

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

3) разработка и тестирование – здесь возможна водопадная модель или использование иных моделей и методов разработки ПО;

4) планирование следующих итераций – анализируются результаты, планы и ресурсы на последующую разработку, принимается (или не принимается) решение о новом витке; анализируется, имеет ли смысл продолжать разрабатывать систему или нет; разработку можно и приостановить, например, из-за сбоев в финансировании; спиральная модель позволяет сделать это корректно. [12]

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

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

Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.

3. Реализация несоответствующей функциональности.

4. Разработка неправильного пользовательского интерфейса.

5. Перфекционизм, ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.

8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9. Недостаточная производительность получаемой системы.

10. Разрыв в квалификации специалистов разных областей. [14]


Рисунок 3. – Этапы спиральной модели.

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

Спиральная модель не нашла широкого применения в индустрии и важна, скорее в историко-методологическом плане: она является первой итеративной моделью, имеет красивую метафору – спираль, – и, подобно водопадной модели, использовалась в дальнейшем при создании других моделей процесса и методологий разработки ПО.[16]

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

Рассмотрим основные шаги процесса:

1. Определение и анализ требований.

7. Сопровождение и эксплуатация.

Статьи к прочтению:

Видео 36. 1, 2 методологии разработки ПО.Модель водопада


Похожие статьи:

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

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

Эта модель обязана своим появлением У. Ройсу ([1], 1970 г.). Модель имеет и другое название – водопад (waterfall). Особенность модели – переход на следующую ступень осуществляется только после того, как будет полностью завершена работа на предыдущей стадии; возвратов на пройденные стадии не предусматривается (рис.5.4).

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

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

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

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

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

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

Итерационная модель ЖЦ ПС

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

В итерационной модели (рис.5.5) недостатки проектирования и программирования могут быть устранены позже путем частичного возврата на предыдущую стадию. Чем ниже уровень обнаружения ошибки, тем дороже ее исправление. Если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на стадии сопровождения – в 20 раз больше (рис.5.6).

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

Макетирование

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

Модель может принимать следующие формы.

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

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

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

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

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

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

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

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

В этой статье Вадим Кулага, проектный менеджер EPAM Anywhere, расскажет об основных моделях разработки программного обеспечения (SDLC), их плюсах и минусах, а также о реальных примерах их использования.

🔀 SDLC модели: как выбрать правильный подход к разработке и не завалить проект

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

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

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

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

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

Плюсы и минусы подхода

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

Каким проектам подходит

Каскадная модель – хороший вариант, если выполняются эти условия:

  • Проект короткий и с нулевым риском.
  • Требования фиксированные.
  • Технологии стабильны.
  • Доступны все необходимые ресурсы.

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

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

🔀 SDLC модели: как выбрать правильный подход к разработке и не завалить проект

Плюсы Минусы
Легко реализовывать. В V-образной модели внести изменения в середине проекта крайне сложно.
Тест-кейсы создаются заранее. При таком большом количестве процедур тестирования остается меньше времени на код.
Бюджет и продолжительность проекта предсказуемы. По сравнению с каскадной эта модель требует больше специалистов.
У каждого этапа есть свои результаты, и все хорошо задокументировано. Модель не подходит для проектов с быстро меняющимися требованиями.
Это структурированный подход с четко определенными ролями и функциями. Не подходит для больших и сложных проектов.

Каким проектам подходит

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

Модель эволюционного прототипирования

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

🔀 SDLC модели: как выбрать правильный подход к разработке и не завалить проект

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

Каким проектам подходит

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

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

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

Каким проектам подходит

Модель будет эффективна в следующих случаях:

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

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

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

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

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

Затем, на основе отзывов пользователей и заинтересованных сторон, планируется следующая итерация.

🔀 SDLC модели: как выбрать правильный подход к разработке и не завалить проект

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

Каким проектам подходит

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

  1. Больших, сложных продуктов, состоящих из нескольких компонентов.
  2. Проектов с частыми релизами.
  3. Проектов средней и высокой степени риска.
  4. Проектов с неясными требованиями.

Microsoft, IBM и Tata Consultancy используют спиральную модель.

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

Вопреки распространённому мнению Agile не является ни структурой, ни методологией. Это философия с набором принципов, ориентированных на ускорение процесса разработки программного обеспечения, обеспечение 100% удовлетворённости клиентов и предоставление высококачественных решений в быстро меняющейся среде. Фактически, существует 12 принципов гибкой разработки, которые сводятся к следующим ценностям:

  • Люди и взаимодействие важнее процессов и инструментов.
  • Рабочее программное обеспечение над обширной документацией.
  • Сотрудничество с клиентами вместо переговоров по контракту.
  • Реагирование на изменения вместо следования плану.

Ценности Agile породили более 50 методологий , из которых Scrum является самой популярной .

Scrum

Скрам-проекты разбиты на спринты. Спринт – это небольшой объём работы, который необходимо выполнить в течение определённого периода времени. Обычно заказчику доставляется часть проекта, которая была завершена во время спринта (инкремент продукта, от англ. increment). Скрам подразумевает активное общение и сотрудничество между всеми участниками проекта. Наряду с ежедневными 15-минутными встречами разработчиков, есть также:

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

Сердце процессов Scrum – это backlog, своего рода список задач, которые необходимо сделать для завершения проекта. По мере того, как проект продвигается, и команда узнаёт о нём больше, они редактируют бэклог продукта, добавляя, удаляя и переупорядочивая его элементы. Тем не менее, нельзя сделать что-то, если этого нет в очереди продукта.

🔀 SDLC модели: как выбрать правильный подход к разработке и не завалить проект

Но на самом ли деле всё так гладко и красиво в Agile? Посмотрим на его основные варианты использования, а также на плюсы и минусы.

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

Примеры использования

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

В общем, Agile кажется именно тем, что нужно большинству проектов во времена неопределённости. Неудивительно, что более 70% компаний применяют Agile , включая Microsoft, IBM, Procter & Gamble и другие. И EPAM не исключение.

Резюме

Вот несколько советов как подходить к разработке на примере реального проекта EPAM Anywhere :

Читайте также: