Знаете ли вы, что существуют различные методологии управления проектами? Каждый из них включает в себя все основные рабочие циклы:

• Разработка требований
• Планирование
• Проектирование
• Кодирование
• Тестирование
• Оптимизация.

Сегодня мы поговорим о двух из них. Тех двух, что мы активно используем на своих проектах. Читаем, анализируем, выбираем. Перед вами сравнение двух методологий — Agile и Waterfall.

Agile

Эта методология базируется на 12 принципах (так называемый Agile манифест). Давайте познакомимся с ключевыми практическими постулатами Agile:

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

В 2015 году было проведено масштабное профессиональное исследование . Под его прицел попал 601 проект из сферы IT. Результат показал, что именно Agile сегодня является самым распространенным подходом к управлению проектами.

Agile: преимущества

• Возможность переделать проект полностью даже после прохождения нескольких итераций.

• Проект разделяется на короткие и прозрачные отрезки (итерации), в Scrum они называются спринтами.

• Гибкость Agile сводит все возможные риски к минимуму.

• Agile идеально подходит для разработки MVP.

Agile: недостатки

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

Waterfall

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

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

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

Waterfall: преимущества

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

Waterfall: недостатки

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

Что же выбрать?

Ваш выбор это Agile, если:

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

Ваш выбор это Waterfall, если:

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

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

Agile и Waterfall: заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одни из самых распространенных категорий моделей разработки ПО – Agile и Waterfall, гибкая и каскадная соответственно. Мы дадим краткое описание каждой, рассмотрим их плюсы, минусы и определимся с корректной системой под проект.

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

При оплате труда разработчиков в рамках Agile обычно выбирают между выделенной командой под проект (Dedicated Team) и системой Time&Materials (T&M). Мы уже сравнили между собой некоторые механизмы построения финансовых отношений с подрядчиком. Наши выводы с позиций клиентов и разработчиков можно найти .

Гибкая модель разработки основана на 12 принципах, из которых определяющими мы считаем следующие:

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

К классу Agile относятся такие методики, как экстремальное программирование (XP), FDD, DSDM, Scrum и другие.

Waterfall

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

1. Анализ требований

2. Планирование

3. Реализация

4. Интеграция

5. Тестирование

7. Поддержка

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

А теперь сравним сильные и слабые стороны Agile и Waterfall.

Плюсы методологий:

Гибкая модель

• Корректировки функциональных требований встроены в процесс разработки для обеспечения конкурентного преимущества. По сути, уже через 2 итерации проект можно развернуть на 360 градусов и делать совсем другой продукт.
• Проект разделен на короткие и прозрачные итерации.
• Минимизация рисков благодаря гибкому процессу внесения изменений.
• Быстрое получение первой рабочей версии продукта.

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

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

Минусы методологий:

Гибкая модель

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

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

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

Изучив матчасть, мы легко научимся жонглировать Agile и Waterfall в своих проектах!

Гибкая модель разработки действует, если:

1. В проекте задействована опытная команда.

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

3. Конечный пользователь «варится» в проекте с самого начала.

4. Необходимо быстро разработать рабочее ПО.

5. Вы стартап.

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

1. Требования к проекту стабильны и практически неизменны;

2. Качество продукта намного важнее затраченного времени и ресурсов;

3. Проект разрабатывается на аутсорсе;

4. Конечный пользователь только принимает результат работы, не участвуя в процессе.

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

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

А теперь просто идите и сделайте свой проект!

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

Каждая методология, выбираемая руководителем проектной команды, подбирается под определенные задачи, стоящие в проекте, а также сроки, выделенный заказчиком бюджет. К тому же, область 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 не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.

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

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