Итеративная модель жизненного цикла проекта
Иногда люди не вполне отчетливо различают работы по управлению проектом и работы жизненного цикла проекта, так как для успешного выполнения проекта необходимы работы обоих видов. Основное различие между ними заключается в том, что управление проектом сосредоточено на определении, планировании, мониторинге и контроле, а также на закрытии проекта. Работы же, связанные с фактическим созданием результатов поставки проекта, принято относить к “жизненному циклу” проекта. В процессе управления проектом создается его график, но подавляющее большинство работ в этом графике составляют именно работы жизненного цикла проекта, в результате выполнения которых появляется выходная продукция.
Несмотря на уникальность всех проектов, подобно тому, как существуют общие процессы управления, применимые к большинству проектов, существуют также и общие модели, которые могут служить руководством по определению жизненного цикла большинства проектов. Эти общие модели ценны тем, что экономят время проектным командам при разработке графика проекта. [4; 34-35]
Примером одной из моделей жизненного цикла является распространенная классическая модель “водопад”. Эта модель представляет базовый подход, который может применяться в любом проекте. Чаще всего Вам приходится начинать с понимания требований к результату проекта, затем следуют проектирование результата, создание и тестирование результата, и завершаете Вы внедрением результата. Каждая из этих областей концентрации внимания называется фазой (фаза анализа, фаза проектирования, фаза реализации и т.д.). Классический “водопадный” подход – это модель жизненного цикла, которую Вы, вероятно, сможете применить, ничего не зная о методологиях и планируя проект “с чистого листа”.
Что может быть проще? Даже если у Вас очень маленький проект, Вы все равно проходите эти базовые шаги, хотя бы даже проделывая некоторые из них в голове. К примеру, если у Вас 40-часовой (на одну рабочую неделю) проект разработки или улучшения документа, может показаться что Вы сразу же бросаетесь в фазу “Реализация”. Но так ли это? Наиболее вероятно, что Вы получили какого-либо рода поручение с требованиями или пожеланиями, которые придется осмыслить (Анализ) и трансформировать в замысел будущего содержания (Проектирование). Затем вы воплощаете замысел (Реализация), проверяете результат (Тестирование) и передаете для использования (Внедрение). [5; 67-71]
Водопадная (каскадная) схема включает несколько важных операций, применимых ко всем проектам:
* составление плана действий по разработке системы;
* планирование работ, связанных с каждым действием;
* применение операции отслеживания хода выполнения действий с контрольными этапами.
Графическая иллюстрация “водопадной модели” проектного цикла
Рисунок.3 Водопадная модель жизненного цикла проекта
Преимущества водопадной (каскадной) модели.
Каскадная модель имеет преимущества, если ее использовать в проекте, для которого она достаточно приемлема.
a. Модель хорошо известна потребителям, не имеющих отношения к разработке и эксплуатации программ, и конечным пользователям.
b. Она упорядоченно справляется со сложностями и хорошо срабатывает для тех проектов, которые достаточно понятны, но все же трудно разрешимы.
c. Она доступна для понимания, так как преследуется простая цель – выполнить необходимые действия.
d. Она проста и удобна в применении, так как процесс разработки выполняется поэтапно.
e. Она отличается стабильностью требований.
f. Она представляет собой шаблон, в который можно поместить методы для выполнения анализа, проектирования, кодирования, тестирования и обеспечения.
g. Она позволяет участникам проекта, завершившим действия на выполняемой ими фазе, принять участие в реализации других проектов.
h. Она определяет процедуры по контролю за качеством. Каждые полученные данные подвергаются обзору. Такая процедура используется командой разработчиков для определения качества системы.
i. Ход выполнения проекта легко проследить с помощью использования временной шкалы (диаграммы Ганта), поскольку момент завершения каждой фазы используется в качестве стадии.
Недостатки каскадной модели.
При использовании каскадной модели для проекта, который трудно назвать подходящим для нее, проявляются следующие недостатки:
a. В основе модели лежит последовательная линейная структура, в результате чего попытка вернуться на одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике.
b. У клиента не всегда есть возможность ознакомиться с системой заранее, это происходит лишь в самом конце жизненного цикла.
c. Клиент не имеет возможности воспользоваться промежуточными результатами, и отзывы пользователей нельзя передать обратно разработчикам. Поскольку готовый продукт не доступен вплоть до окончания процесса, пользователь принимает участие в процессе только в самом начале – при сборе требований, и в конце во время приемочных испытаний.
d. Каждая фаза является предпосылкой для выполнения последующих действий, что превращает такой метод в рискованный выбор для систем, не имеющих аналогов, так как он не поддается гибкому моделированию.
e. Для каждой фазы создаются результативные данные, которые по его завершении считается замороженными. Это означает, что они не должны изменяться на следующих этапах жизненного цикла продукта. Если элемент результативных данных какого-либо этапа изменяется, на проект окажет негативное влияние изменение графика, поскольку ни модель, ни план не были рассчитаны на внесение и разрешение изменения на более поздних этапах жизненного цикла.
f. Все требования должны быть известны в начале жизненного цикла, но клиенты не всегда могут сформулировать все четко заданные требования на этот момент разработки.
В то время, как “водопад” универсален и может применяться в любом проекте, другие модели жизненного цикла могут оказаться более результативными и эффективными в зависимости от характеристик проекта. Например, если Вы устанавливаете пакет программного обеспечения, Вы пропускаете фазы проектирования и реализации. Подобным же образом, если Вы занимаетесь опытно-конструкторскими разработками, Вы можете использовать специфическую модель жизненного цикла R&D проекта, учитывающую, что проделанная работа или часть ее может пойти в мусорную корзину. Другие важные модели жизненного цикла могут использоваться для ускорения проектов определенного вида. Проекты в области информационных технологий, к примеру, часто используют итеративную либо быструю (Agile development) разработку. [6; 23-25]
Ниже приведены некоторые другие модели жизненного цикла проекта:
Итеративный подход (англ. iteration — повторение) — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle).
Преимущества итеративного подхода:
1. снижение воздействия серьезных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;
2. организация эффективной обратной связи проектной команды с потребителем (а также заказчиками, стейкхолдерами) и создание продукта, реально отвечающего его потребностям;
3. акцент усилий на наиболее важные и критичные направления проекта;
4. непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;
5. раннее обнаружение конфликтов между требованиями, моделями и 6.реализацией проекта;
7. более равномерная загрузка участников проекта;
8. эффективное использование накопленного опыта;
9. реальная оценка текущего состояния проекта и, как следствие, большая 10.уверенность заказчиков и непосредственных участников в его успешном завершении. [7; 240-243]
Спиральная модель жизненного цикла проекта. В рамках этой модели рассматривается зависимость эффективности проекта от его стоимости с течением времени. На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка.
Спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков
1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. “Разрыв” в квалификации специалистов разных областей знаний.
Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.
Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.
Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:
оценка и разрешение рисков,
определение целей,
разработка и тестирование,
планирование.
Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты.
Преимущества спиральной модели:
При использовании спиральной модели при выполнении проекта, для которого она в достаточной мере подходит, появляются следующие преимущества:
a Спиральная модель разрешает пользователям «увидеть» систему на ранних этапах, что обеспечивается посредством использования ускоренного прототипирования в жизненном цикле разработки проекта.
b Обеспечивается определение непреодолимых рисков без особых затрат.
c Модель разрешает пользователям активно принимать участие при планировании, анализе рисков, разработке, а также при выполнении оценочных действий.
d Она обеспечивает разбиение большого потенциального объема работы по разработке продукта на небольшие части.
e В модели предусмотрена возможность гибкого проектирования, поскольку в ней воплощены преимущества каскадной модели, и в то же время разрешены итерации по всем фазам этой же модели.
f Реализовано преимущество инкрементной модели, а именно выпуск инкрементов, сокращение графика посредством перекрывания инкрементов и неизменяемость ресурсов при постепенном росте системы.
Недостатки спиральной модели:
При использовании спиральной модели относительно проекта, для которого она не подходит в достаточной мере, проявляются следующие недостатки:
a Спираль может продолжаться до бесконечности.
b Большое количество промежуточных стадий может привести к необходимости в обработке внутренней дополнительной и внешней документации.
c Использование модели может стать дорогостоящим, так как время, затраченное на планирование, повторное определение целей, анализа рисков и прототипирование, может быть чрезмерным. [8; 312-316]
Инкрементная модель проектного цикла. Эта модель в большинстве случаев применяется при проведении сложных опытно-конструкторских работ, которые требуют большого количества участников, множества различных вопросов, которые необходимо решить. Ее суть заключается в разбиении большого объема работ на последовательность более мелких составляющих частей. Она представляет собой процесс частичной реализации всей системы и медленного наращивания функциональных возможностей или эффективности.
Эта модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результаты финальной итерации содержит всю требуемую функциональность продукта.
Преимущества инкрементной модели.
Применяя инкрементную модель при разработке проекта, для которого она подходит в достаточной мере, можно убедиться в следующих ее преимуществах:
a Не требуется заранее тратить средства на разработку всего проекта.
b В результате выполнения каждого инкремента получается функциональный продукт.
c Использование последовательных инкрементов позволяет объединить полученные пользователями опыт в виде усовершенствованного продукта, затратив при этом намного меньше средств, чем требуется для выполнения повторной разработки.
d Правило по принципу «разделяй и властвуй» позволяет разбить возникшую проблему на управляемые части, благодаря чему предотвращается формирование громоздких перечней требований, выдвигаемых перед командой разработчиков.
e В процессе разработки можно ограничить количество персонала таким образом, чтобы над поставкой каждого инкремента, последовательно работала одна и та же команда.
f В конце каждой инкрементной поставки существует возможность пересмотреть риски, связанного с затратами и соблюдением установленного графика.
g Поскольку переход из настоящего в будущее не происходит моментально, заказчик может привыкать к новой технологии постепенно.
h Риск распределяется на несколько меньших по размеру инкрементов, и не сосредоточен в одном большом проекте разработки.
Недостатки инкрементной модели.
При использовании этой модели относительно проекта, для которого она подходит не в достаточной мере, проявляются следующие недостатки:
a В модели не предусмотрены итерации в рамках каждого инкремента.
b Определение полной функциональной системы должно осуществляться в начале жизненного цикла, чтобы обеспечить определение инкрементов.
c Заказчик должен осознавать, что общие затраты на выполнение проекта не будут снижены. [9; 90-94]
Источник
Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.
1. «Waterfall Model» (каскадная модель или «водопад»)
Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.
С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний — рентгеновский микротомограф, мелкий — автообновление службы Windows на AWS.
Когда использовать каскадную методологию?
- Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
- Нет проблем с доступностью программистов нужной квалификации.
- В относительно небольших проектах.
2. «V-Model»
Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.
Пример нашей работы на основе V-методологии — мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.
Когда использовать V-модель?
- Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
- Для малых и средних проектов, где требования четко определены и фиксированы.
- В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.
3. «Incremental Model» (инкрементная модель)
В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.
Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.
Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену 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 этапа для каждого витка:
- планирование;
- анализ рисков;
- конструирование;
- оценка результата и при удовлетворительном качестве переход к новому витку.
Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование. На проекте по разработке СЭД для ОДУ Сибири СО ЕЭС два совещания об изменении кодификации разделов электронного архива занимают в 10 раз больше времени, чем объединение двух папок программистом. Государственные проекты, в которых мы участвовали, начинались с подготовки экспертным сообществом дорогостоящей концепции, которая отнюдь не всегда бесполезна, поскольку окупается в масштабах страны.
Подытожим
На слайде продемонстрированы различия двух наиболее распространенных методологий.
В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.
О технологиях разработки:
Ещё раз про семь основных методологий разработки.
10 главных ошибок масштабирования систем.
8 принципов планирования разработки, упрощающих жизнь.
5 главных рисков при заказной разработке ПО.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Источник