Основная статья: Модель водопада
Водопадная модель жизненного цикла (англ. waterfall model ) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью:
1. Формирование требований;
2. Проектирование;
3. Реализация;
4. Тестирование;
5. Внедрение;
6. Эксплуатация и сопровождение.
Преимущества :
· Полная и согласованная документация на каждом этапе;
· Легко определить сроки и затраты на проект.
Недостатки :
В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы . Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем .
Итерационная модель
Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID ), получившей также от Т. Гилба в 70-е гг. название эволюционной модели . Также эту модель называют итеративной моделью и инкрементальной моделью .
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации - получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение - инкремент - к его возможностям, которые, следовательно, развиваются эволюционно . Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения .
По выражению Т. Гилба, «эволюция - прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте» .
Подход IID имеет и свои отрицательные стороны, которые, по сути, - обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже» .
Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).
Спиральная модель
Спиральная модель (англ. spiral model ) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются:
· риск превышения сроков и стоимости проекта;
· необходимость выполнения ещё одной итерации;
· степень полноты и точности понимания требований к системе;
· целесообразность прекращения проекта.
Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID .
Отличительной особенностью спиральной модели является специальное внимание, уделяемое рискам, влияющим на организацию жизненного цикла, и контрольным точкам. Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:
1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. Перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. Разрыв в квалификации специалистов разных областей.
В сегодняшней спиральной модели определён следующий общий набор контрольных точек :
1. Concept of Operations (COO) - концепция (использования) системы;
2. Life Cycle Objectives (LCO) - цели и содержание жизненного цикла;
3. Life Cycle Architecture (LCA) - архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
4. Initial Operational Capability (IOC) - первая версия создаваемого продукта, пригодная для опытной эксплуатации;
5. Final Operational Capability (FOC) –- готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.
Что такое водопадная модель
Жизненным циклом ПО называется период существования ПО, связанный с подготовкой к его разработке, разработкой, использованием и переработками, начиная с того момента, когда принимается решение разработать новую систему до того момента, когда полностью прекращается всякое ее использование. Модель жизненного цикла ПО выделяет конкретные наборы видов деятельности, артефактов, ролей и их взаимосвязи. Она определяет, какие артефакты являются входными данными у каких видов деятельности, и какие артефакты появляются в качестве результатов, какие роли вовлечены в различные работы, как работы соотносятся друг с другом по времени, каковы критерии качества полученных результатов, как оценить степень соответствия различных артефактов общим задачам проекта и когда можно переходить от одной деятельности к другой.
Водопадная модель жизненного цикла ПО предполагает последовательное выполнение различных этапов деятельности, включая анализ требований, проектирование, кодирование и тестирование отдельных модулей (компонентов), тестирование сборок и интегрированное тестирование всего конечного продукта. При этом предполагается четкое разграничение этапов, на которых набор документов, выработанный на предыдущей этапе, передается в качестве входных данных для следующего. Таким образом, каждый вид деятельности выполняется на какой-то одной фазе жизненного цикла ПО, движение в обратную сторону по этой цепочке невозможно.
Этапы деятельности
Анализ. На этапе анализа изучается и определяется задача, которую должна выполнять программа. Результатом выполнения этой фазы является совокупность требований, предъявляемых к ПО.
Проектирование. На этом этапе требования, выявленные при анализе, преобразуются в описание принципов решения – документ, в соответствии с которым принимаются конкретные решения при реализации программы. Основным итогом второй фазы является получение проекта, который может включать текст на естественном языке, модель ПО, алгоритмы, таблицы, математические формулы и т. п. Детальное проектирование предполагает выделение компонент ПО, определение их структуры и методов взаимодействия.
Реализация. По завершении исходного проектирования следует этап реализации, на котором создаются и тестируются программные модули, определенные при проектировании. Главными результатами этого этапа являются модули исходного кода и автономные тесты модулей. После реализации переходят к тестированию системы, а затем к сдаче ее в эксплуатацию.
Внедрение и эксплуатация. Готовый программный продукт передается заказчику, производятся приемо-сдаточные испытания, осуществляется обучение пользователей и опытная эксплуатация, после чего ПО ставится на сопровождение и начинается производственная эксплуатация программной системы.
Недостатки водопадного подхода
- Накопление различных ошибок, допущенных на ранних стадиях проекта. Если только к концу проекта, становится очевидно, что были допущены ошибки, то любой возврат к предыдущим стадиям с целью исправления ошибок становится крайне дорогостоящим. Метод "водопада" не позволяет эффективно выявлять и нивелировать последствия подобных рисков.
- Неоправданное увеличение времени реализации, превышение бюджета и риск полного срыва проекта из-за накопления ошибок от этапа к этапу.
- Все ключевые решения принимаются тогда, когда у аналитиков и разработчиков нет полного понимания системы. Очень сложно уложить реальный процесс создания программного обеспечения в такую жесткую схему, поэтому постоянно возникает необходимость возврата к предыдущим этапам с целью уточнения и пересмотра ранее принятых решений. В начале проекта перед разработчиками стоит обескураживающая задача: полностью определить все требования к системе. Для этого необходимо тщательно и всесторонне обсудить с пользователями и исследовать бизнес-процессы. Пользователи должны согласиться со всем тем, что выясняется в ходе такого обследования, хотя они могут и не ознакомиться до конца с его результатами. При некотором везении таким способом на стадии анализа удается собрать около 80% требований к системе. При проектировании могут возникнуть новые проблемы, их необходимо опять обсуждать с пользователями, что выразится в появлении новых требований к системе. В процессе реализации и тестирования зачастую обнаруживается, что некоторые из принятых ранее решений невозможно осуществить или выясняется, что требования не были достаточно детализированы и их реализация некорректна. Нужно возвращаться назад на этап анализа и пересматривать эти требования.
- Метод водопада не дает возможности быстрой адаптации к изменениям , особенно на поздних стадиях жизненного цикла ПО.
- Конечный продукт может оказаться невостребованным из-за неточного изложения требований или их изменения за длительное время создания ПО.
Когда применяется водопадный подход
Водопадный подход хорошо работает в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется. То же касается проектов ПО, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объем пользовательского интерфейса невелик.
Сравнение водопадного и итеративного подходов
На приведенном рисунке хорошо видны различия водопадного и итеративного подходов. Водопадный подход предполагает фиксацию функциональности ПО и возможность варьирования времени и ресурсов (обычно в сторону увеличения по причинам, приведенным выше).
При водопадном подходе заказчик привлекается к участию в проекте только на раннем этапе (для определения требований к ПО) или в случае необходимости внесения изменений, обнаруженной разработчиками. Он может оценить только конечный результат, который может не соответствовать его представлениям.
В итеративном подходе предполагается участие представителя заказчика в проекте на всех этапах. Итеративный подход позволяет существенно облегчить и упростить процесс изменения функциональности ПО.
Основные преимущества итеративного подхода можно сформулировать так:
- Возможность нивелирования воздействия серьезных рисков на ранних стадиях проекта, пока это еще можно сделать с минимальными затратами. Разница стоимости ошибки определения требований в начале проекта и в конце равна 1:200.
- возможность организовать плодотворную обратную связь с будущими конечными пользователями с целью создания системы, реально отвечающей их потребностям;
- акцент усилий на наиболее важные и критичные направления проекта;
- непрерывное итеративное тестирование конечного продукта, позволяющее оценить успешность всего проекта в целом;
- раннее обнаружение несоответствий между требованиями, моделями и программным кодом;
- эффективное использование накопленного опыта;
- реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.
В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.
В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:
- Определение требований
- Проектирование
- Конструирование (также «реализация» либо «кодирование»)
- Воплощение
- Тестирование и отладка (также «верификация»)
- Инсталляция
- Поддержка
Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей
Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка - внесение новой функциональности и устранение ошибок.
Тем самым, каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз - не происходит.
Тем не менее, существуют модифицированные каскадные модели (включая модель самого Ройса), имеющие небольшие или даже значительные вариации описанного процесса.
Критика каскадной модели и гибридные методологические решения
Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству. Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным . Поэтому даже в PMBOK 3-ей версии формально была закреплена только методика «каскадной модели» и не были предложены альтернативные варианты, известные как итеративное ведение проектов .
Начиная с PMBOK 4-ой версии удалось достичь компромисса между методологами , приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы . Таким образом, начиная с 2009 года, формально предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов.
См. также
Примечания
Ссылки
- Royce, Winston (1970), Managing the Development of Large Software Systems (англ.)
| Разработка программного обеспечения | |
|---|---|
| Известные деятели |
|
| Процесс | |
| Концепции | |
| Направления | |
| Модели разработки |
|
| Другие модели | |
| Прочее | |
Wikimedia Foundation . 2010 .
Смотреть что такое "Каскадная модель" в других словарях:
В компьютерных вычислениях Модель хаоса это способ разработки программного обеспечения. Ее создатель Л.Б.С.Ракун отмечает, что такие модели управления проектами, как спиральная модель и каскадная модель, хотя и хороши в управлении расписаниями и… … Википедия
В классической теории баз данных, модель данных есть формальная теория представления и обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта: 1) аспект структуры: методы описания типов и… … Википедия
Запрос «CSS» перенаправляется сюда. Но у этой аббревиатуры могут быть и другие значения см. CSS (значения). CSS (англ. Cascading Style Sheets каскадные таблицы стилей) технология описания внешнего вида документа, написанного языком разметки.… … Википедия
В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия
Это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из… … Википедия
Жизненный цикл информационной системы это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в… … Википедия
- (ЭИС) представляет собой совокупность организационных, технических, программных и информационных средств, объединённых в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для выполнения функций… … Википедия
Экономическая информационная система (ЭИС) представляет собой совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации,… … Википедия
Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование … Википедия
Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия
К сожалению, не существует универсального процесса разработки ПО, полностью подходящего под каждый проект. Во главе угла стоят методологии – системы стандартов, содержащие понятия, методы и способы, которые определяют стиль создания программного обеспечения.
Методология подбирается, во-первых, под конкретные задачи, объемы работ, цели заказчика и бюджет. Во-вторых, не забываем и про специфику деятельности 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. Конечный пользователь только принимает результат работы, не участвуя в процессе.
Необходимо сказать, что обе модели помогут реализовать ваш проект. В первую очередь вы выбираете вариант, который позволит вам делать качественные продукты и эффективно управлять своим бюджетом.
Конечно, как только вы на финишной прямой, никого не будет интересовать выбранная методология. Поэтому, даже если модель разработки оказалась неподходящей, команда должна быть достаточно сильной для получения достойных результатов.
А теперь просто идите и сделайте свой проект!
Методология разработки софта - организация труда, включающая идеологические принципы, план, контроль над процессами, подход к сотрудникам. Выделим 12 видов:
- Waterfall - традиционный подход.
- RUP (Rational Unified Process) - рациональный.
- Agile - общая методология гибкой разработки.
- Crystal Clear - подход с уравниванием разработчиков в коллективе.
- Spiral - спиральный метод.
- DSDM (Dynamic Systems Development Model) - динамическая модель.
- FDD (Feature Driven Development) - методология, рассматривающая будущие изменения.
- JAD (Joint Application Development) - ориентированный на пользователя подход.
- RAD (Rapid Application Development) - модель быстрой разработки.
- Scrum - концепция работы в условиях сорванных сроков и идеологического кризиса.
- XP (Extreme Programming) - экстремальная разработка в динамической среде.
- LD (Lean Development) - метод, предполагающий бережное отношение ко всем участникам процесса.
Давайте попробуем разобраться, что скрывается за этими английскими названиями.
Waterfall
Модель Waterfall относится к классическому пониманию разработки ПО. Весь процесс является жестким и линейным, имеет четкие цели для каждого этапа, новая фаза начинается по завершению предыдущей, нет возврата назад. Преимущества водопадной методологии - децентрализация и строгий контроль над сроками и качеством исполнения.
На практике Waterfall часто не оправдывает ожиданий, поскольку игнорирует динамические изменения. Так, после тестирования очень сложно откатить процесс и заложить функции, не учтенные на стадии разработки. Waterfall неэффективен ещё и потому, что предполагает временные простои сотрудников в рамках одного проекта. Тестирование проводится только в конце разработки, хотя проблемы, найденные на этом этапе - это дорогостоящие исправления.
RUP
RUP - итеративный подход, который решает проблемы, которые есть у Waterfall. Чем хорош RUP:
- Учитывает изменяющиеся требования. Как бы ни был хорош руководитель проекта, учесть всё в начале невозможно.
- Интеграция функций происходит постепенно, то есть каждая «деталь» проходит цикл разработки, проверки и внедрения в проект. Как следствие, снижаются риски и стоимость производства.
- Ранний выпуск продукта. ПО выходит с уменьшенной функциональностью, чтобы занять нишу на рынке и противостоять конкурентам, после чего обрастает «мясом».
- Повторное использование. При наращивании функциональности проще выделить типовые решения, которые сократят разработку.
- Постоянное обучение. Из-за частых итераций разработчики не имеют больших пауз между доработкой кода, поэтому профессиональный рост происходит плавно и безболезненно.
- Постоянное улучшение продукта. Итерации позволяют оценить проект не только с точки зрения соответствия плану и ТЗ, но и найти пути увеличения эффективности и качества продукта.
Agile
Agile - метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идей и 12 принципов гибкого подхода, коротко его можно описать всего двумя пунктами:
- Неформальные отношения важнее задокументированных. То есть устные договоренности между сотрудниками, между заказчиком и исполнителем важнее всего, что отражено в планах, договорах и техническом задании. Иначе говоря, клиент всегда прав.
- Работающий продукт - главная оценка прогресса. Важны не инструменты, решения, производительность и изящество, а тот факт, что все запланированные возможности реализованы.
Несмотря на недостатки, Agile стала фундаментальной концепцией для разработки ПО и нашла отражение в других методологиях, речь о которых пойдет далее.
Crystal Clear
Методология, созданная для небольших коллективов из 6−10 сотрудников. Также поддерживает принципы гибкой разработки, но имеет чуть больше конкретики. Основная идея, которая и заключена в названии - каждая команда является набором людей с разным уровнем знаний, разными умениями и опытом.
Именно поэтому нет универсального подхода для разработки софта, он должен определяться в процессе общения внутри группы. Там же назначаются роли, инструменты, стандарты. Затем группа принимается за единицу и те же самые вопросы решаются на уровень выше, пока иерархия не дойдет до заказчика.
Spiral
Модель спирального жизненного цикла - это сложная организация жизненного цикла ПО, которая фокусируется на раннем выявлении и уменьшении проектных рисков. Разработка начинается в небольшом масштабе, решаются локальные задачи, оцениваются риски и пути их уменьшения. Следующий шаг охватывает более комплексные задачи - следующий виток спирали.
Преимущество подхода не в увеличении скорости разработки, а в снижении уровня возникновения рисков. Успешность спирального метода зависит от добросовестного, внимательного и компетентного управления, а размер проекта не имеет принципиального значения.
DSDM
Модель развития динамических систем была разработана в Великобритании в середине 1990-х годов и является эволюционным развитием быстрой разработки приложений (RAD). Основная идея стандартная: при планировании в самом начале невозможно понимать всех тонкостей разработки, поэтому весь процесс - исследовательская работа.
В DSDM тоже присутствует деление на команды, в каждой из которых есть уполномоченный для принятия стратегических решений. В процессе могут участвовать все заинтересованные стороны: пользователи, разработчики, заказчики, руководители. Тестирование проводится на протяжении всего жизненного цикла.
FDD
FDD - процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Вот основные принципы:
- Разработка каждого крупного проекта должна иметь системность.
- Процессы должны быть простыми и проработанными.
- Ценность и логичность процесса должна быть ясна каждому члену команды.
- Предпочтение отдаётся коротким итеративным циклам разработки. Это уменьшает количество ошибок и позволяет быстрее наращивать функциональность.
FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.
JAD
JAD - это методология, нацеленная на максимальную занятость в разработке конечного пользователя. Происходит это посредством встреч и проведения совместных семинаров. JAD была придумана в 1970-х годах сотрудниками IBM и нацелена на бизнес в целом. Однако со временем данная концепция стала успешно применяться и для разработки программного обеспечения.
В отличие от подхода Waterfall, JAD приводит к сокращению времени разработки, большей удовлетворенности клиентов и экономии средств на изучении рынка. С другой стороны, это требует большой клиентской выборки и необходимости разработчиков работать не со строгими требованиями ТЗ, а с постоянно меняющимся мнением.
RAD
RAD - методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий - использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). Вот ещё несколько пунктов концепции:
- Использование фокус-групп для сбора требований.
- Прототипирование и пользовательское тестирование конструкций.
- Повторное использование программных компонентов.
- Использование плана, не включающего переработку, или дизайн следующей версии продукта.
- Проведение неформальных совещаний по запросу одной из сторон.
RAD предполагает использование целого комплекса инструментов помимо языка быстрой разработки: системы сбора требований, среды разработки, фреймворки, программы для группового общения, ПО для тестирования.
Scrum
Scrum - гибкий метод управления проектами, целью которого является повышение производительности труда в командах, ранее парализованных более тяжелыми методологическими процессами. В основе концепции лежат «спринты». Спринт - короткая итерация, строго ограниченная по времени (обычно 2−4 недели). В это время минимизируется длительность совещаний, но увеличивается их частота (они называются «схватками»).
Благодаря этому контроль за выполнением становится более гибким, а разработчики быстрее реагируют на возникающие проблемы. Традиционное планирование отходит на второй план, его место занимает журнал спринтов.
XP
Экстремальное программирование - возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:
- Игра в планирование. В начале проекта есть только приблизительный план, после каждой итерации его чёткость возрастает.
- Высокая частота релизов. Новая версия продукта имеет незначительные изменения по сравнению с предыдущей, но время на выпуск при этом минимально.
- Контакт с клиентом. Для удовлетворения требований конечной аудитории необходимо оперативное реагирование на замечания и пожелания.
- Рефакторинг. Улучшение качества кода без уменьшения функциональности.
- Стандарт выполнения кода. Или применяются общие правила, или разногласия в оформлении не подлежат обсуждению и критике.
- Коллективная ответственность. Несмотря на то, что каждый член команды выполняет свой участок работ, за код в целом отвечает весь коллектив.
LD
Бережливая разработка ПО - ещё одно ответвление гибкой методологии, предполагающее сохранение высокого морально-функционального состояния разработчиков. Это выражается в:
- Поощрении сотрудников за успешную работу.
- Изменении текущих задач только по мере необходимости или по запросу заказчика.
- Строгом выполнении плана: всё, что сверх - считается потерями времени и ресурсов.
- Внедрении общей концепции «Мыслить широко, делать мало, ошибаться быстро, учиться стремительно».
В условиях короткого дайджеста трудно раскрыть все преимущества и недостатки методологий, показать эффективные области применения. О наиболее актуальных на сегодняшний день концепциях мы поговорим отдельно. О каких именно? Оставляйте свои пожелания в комментариях.
