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

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

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

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

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

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

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

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

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

1. Сбор требований и создание документации.
2. Дизайн и проектирование системы.
3. Реализация.
4. Тестирование и развертывание.
5. Поддержка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agile

Метод реализации проектов Agile основан на итерациях. Весь процесс разработки нового программного продукта разделяется на несколько циклов протяженностью 1-4 недели. Каждый этап рассматривается как отдельный микропроект, в котором есть подготовительный этап, этап планирования, создания и этапа, на котором происходит проверка совместимости продукта с требованиями заказчика. Результатом каждой итерации становится продукт с определенным набором технических характеристик, который можно показать заказчику для внесения корректировок, если это потребуется.

Вся разработка ПО с использованием методологии Agile подчинена 12 ключевым принципам. Ключевыми же являются:

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

К гибким методам Agile чаще всего относят такие методы программирования, как Scrum, FDD и другие.

Waterfall

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

• Исследование необходимых требований к конечному продукту;
• Планирование работ по разработке ПО;
• Создание продукта;
• Интеграция;
• Выполнение тестовых мероприятий;
• Выпуск нового программного продукта;
• Техническая поддержка и сопровождение.

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

Достоинства методов разработки

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

Waterfall

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

Недостатки методов разработки

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

Waterfall

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

Выбирать необходимо, если удовлетворены следующие условия:

• Члены команды – опытные сотрудники;
• Окончательные параметры продукта неопределенны, а изменения должны вноситься в максимально короткие сроки;
• Заказчик участвует в создании продукта с самого начала;
• Нужна скорость разработки;
• Если создание программного продукта является стартапом.

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

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

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

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

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

Программирование ,

Разработка мобильных приложений

Разработка программного продукта знает много достойных методологий - иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне .

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

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

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний - , мелкий - .

Когда использовать каскадную методологию?

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

2. «V-Model»

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

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

Когда использовать V-модель?

• Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

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

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

Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.

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

Когда использовать инкрементную модель?

• Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
• Требуется ранний вывод продукта на рынок.
• Есть несколько рисковых фич или целей.

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

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

Модель быстрой разработки приложений включает следующие фазы:

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

Когда используется RAD-модель?

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

5. «Agile Model» (гибкая методология разработки)

В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.

В основе такого типа - непродолжительные ежедневные встречи - «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

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

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

Когда использовать Agile?

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

6. «Iterative Model» (итеративная или итерационная модель)

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

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

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

Когда оптимально использовать итеративную модель?

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

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

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

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

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

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

Подытожим

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

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

О технологиях разработки:
.
.
.
.

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

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

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

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

Первоначально налогом облагалась стоимость валового оборота товара предприятия многоступенчатым (каскадным), или так называемым кумулятивным, методом, при котором налог взимался на каждой стадии производства или обращения товара (исключая обороты внутри компании). Такая система действовала в ФРГ, Бельгии, Австрии и других государствах до конца 60-х гг. Многократность обложения обременяла товар налогами и затрудняла организацию платежа, так как требовала использования большого количества документов. Более простой способ обложения, к которому перешло большинство государств, - взимание налога с оборота один раз - на стадии производства , оптовой или розничной торговли , но по более высокой ставке. Однократное обложение по обороту товара в производстве, с одной стороны, сдерживает централизацию промышленных и торговых предприятий, так как возрастает сумма налога в связи с обложением не только производственных, но  

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

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

В настоящее время на ряде предприятий в гальваническом производстве используется морально устаревшее оборудование, не поддающееся автоматизации. Это приводит к значительным перерасходам воды на промывку. Внедрение более совершенных полуавтоматизированных и автоматизированных систем для каскадных промывных операций позволяет сократить расход свежей воды на 30-35%. Сокращение потребления свежей воды позволит одновременно решить задачу и повышения качества покрытий, так как из-за больших расходов воды на промывку трудно осуществить и надлежащую подготовку воды для гальванического производства. В автомобильной промышленности, в приборостроении, тракторном и сельскохозяйственном машиностроении уже нашли применение каскадные методы промывки, приводящие-к сокращению расхода свежей воды на 35-40%. На предприятиях тяжелого, энергетического и транспортного машиностроения , станкостроения в основном применяются стационарные гальванические линии, потребляющие большое количество свежей воды.  

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

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

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

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

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

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

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

Разработки ПО. Сегодня речь пойдёт о самой популярной из них – Waterfall, или каскадной методологии.

Общая концепция подхода была представлена доктором Уинстоном Ройсом ещё в 1970 году. В его основе лежит логическая последовательность шагов, которые должна быть предприняты на протяжении жизненного цикла разработки ПО. Каждый этап согласовывает компетентными сотрудниками, документируется и передаётся дальше.
Хотя популярность модели Водопада за последние годы ослабела, природа последовательного процесса, используемого в методе водопада, интуитивно ближе разработчикам, и потому доминирует в IT.

Как падает вода

Модель, предложенная Ройсом, предельно проста и понятна. Она состоит из 7 блоков, каждый из которых охватывает свою область ответственности.

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

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

Мы также сократим указанную модель до 6 блоков, объединив операции «Инсталляция» и «Поддержка» в одну – «Развертывание». Теперь взглянем на исполняемые функции:

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

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

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

Воплощение . Исполнительский этап, на который, как правило, приходится большая часть разработки. Если классическая модель допускает свободное взаимодействие с предыдущими этапами, то на практике допускается лишь внесение незначительных правок в «Конструирование».

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

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

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

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

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

• Устойчива к изменению кадрового состава. Разработчики могут приходить и уходить на протяжении всего жизненного цикла проекта, но благодаря подробному документированию это практически не влияет на сроки исполнения проекта.
• Дисциплина. Модель водопада заставляет разработчиков, вовлечённых в проект быть дисциплинированными, оставаться в рамках намеченного плана. При необходимости в общей модели добавляется орган управления, ответственный за принятие решений, исполнители же обязаны работать в рамках системы.
• Гибкость на ранних этапах. Изменения в первых трёх фазах могут быть сделаны немедленно и с минимальными усилиями, поскольку они не подкреплены кодом. Таким образом, заказчик и исполнитель имеют значительный временной запас для кардинального изменения концепции работы ПО.
• Ориентация на сроки и финансы. Благодаря тому, что каждый этап полностью очерчивает контур будущего ПО, все разработчики понимают свою роль, границы работы и сроки исполнения. Это позволяет оперировать реальными цифрами перед заказчиком, что делает модель проекта привлекательной.

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

В 1970-х годах идеи Ройса были актуальны. Но спустя почти 50 лет метод каскадной разработки всё меньше подходит для IT. Вот почему:

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

Получается, что каскадная методология – прекрасное решение точки зрения сроков и отчётности, но очень слабое в плане качества. Поэтому сегодня её рекомендуется использовать только в трёх случаях:

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

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