Именно на этом этапе все требования к продукту и к команде разработчиков прописываются на бумаге и утверждаются с обеих сторон. В современных условиях быстрая разработка – это очень модный подход, и ее используют все активнее. Основное преимущество состоит в том, что сравнительно небольшие группы разработчиков способны справляться с проектами за то же время, которое необходимо при применении более традиционных методов командами на порядок большей численности. Филипп Крачтен долгое время работает в фирме Rational Software, которая сейчас принадлежит IBM. Именно по этой причине итеративная модель стала основой RUP (Rational Unified Process) – одного из наиболее распространенных методов комплексного управления процессом разработки ПО. На ее же основе разработан главный конкурент RUP со стороны Microsoft – MSF (Microsoft Solutions Framework), а также аналогичный подход компании Borland – ALM (Application Lifecycle Management).
- Следуя этой модели, специалисты не могут перейти к новому этапу, не закончив предыдущий.
- Проектная документация с этапа разработки концепции разбивается на выполнимые задания.
- Стадия — часть процесса создания ПО, ограниченная определёнными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.
- Но в некоторых случаях именно этот этап и четко задокументированные требования защищают заказчика и разработчиков от неприятных ситуаций и претензий.
- Строя систему короткими итерациями, можно гарантировать соответствие требованиям потребителя до того, как построить целую систему.
На этом этапе можно использовать Confluence — отличный инструмент для обмена проектными файлами и разработки документации по исследованию продукта. В ходе этой встречи менеджер представляет проект и его цели, обсуждает с командой важнейшие этапы плана, отвечает на вопросы, а также знакомит всех с инструментами, которые команда будет использовать в процессе работы. После общего собрания каждый из членов команды должен иметь четкое представление о проекте в целом, его этапах и их реализации. Четкое понимание этих фаз позволяет менеджерам и руководителям максимально эффективно контролировать проекты. Целью жизненного цикла является создание простой в использовании структуры для руководства и управления проектами. Иными словами, независимо от того, какая методология выбрана для управления проектом, у каждого из них всегда будет начало, середина и завершение.
Практики на протяжении жизненного цикла разработки ПО
Кроме этого, необходимо убедиться в том, что все участники правильно поняли поставленные задачи и то, как именно каждое требование будет реализовано на практике. Итерационная модель предполагает разбиение проекта на части (этапы, итерации) и прохождение этапов жизненного цикла на каждом их них. Каждый этап является законченным сам по себе, совокупность этапов формирует конечный результат. У программного обеспечения, как у живого существа есть свой жизненный цикл.
В разработке ПО она применяется главным образом в небольших и четко определенных проектах. Если тестирование выявило недоработки, продукт возвращается к первому этапу и процесс повторяется заново. Очевидным преимуществом этой модели является ее простота, однако в настоящее время она годится только для разработки самых простых проектов или решения учебных задач. Стоит понимать, что спиральную модель стоит применять в проектах такого типа, для которого она изначально была предназначена.
Современные модели
Этот цикл повторяется до тех пор, пока все требования не будут реализованы. На стадии проектирования (называемой также стадией дизайна и архитектуры) программисты и системные архитекторы, руководствуясь требованиями, разрабатывают высокоуровневый дизайн системы. Каскадная модель хорошо зарекомендовала себя при построении относительно простых ПО, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к продукту. После того, как будут сформулированы ответы, можно разрабатывать и предлагать конкретные проектные решения. Например, на этом этапе разрабатывается и утверждается дизайн сайта.
В связи с тем что заказчик достаточно часто не является специалистом в области ПО, он обычно плохо воспринимает «голые» спецификации продукта. Он позволяет значительно улучшить взаимопонимание между всеми участниками процесса за счет последовательного, эволюционного развития системы на основе итеративного уточнения прототипов. Первой моделью, получившей широкую известность и действительно структурирующей процесс разработки, является каскадная или водопадная.
Для решения описанных проблем была выдвинута другая модель – итеративная (инкрементальная). Когда документы подписаны и условия финально утверждены заинтересованными сторонами, начинается стадия планирования. Задача этого этапа — определение общих целей, реализация которых приведет каждую из сторон к желаемому результату. Для управления рисками в области применения передовых технологий, и сведения к минимуму дорогостоящих технических или управленческих ошибок, МО США разработало руководство, содержащее все необходимые принципы разработки систем.
В каждом из циклов присутствует этапы проектирования, разработки, тестирования и развертывания на основном сервере для показа заказчику или фокус-группе. После того, как стали понятны функциональные требования и стек технологий, можно переходить к проектированию и дизайну. На этом этапе разработчики проектируют будущую архитектуру проекта в выбранной технологии. Создается адаптивный и юзабельный дизайн, продумывается связь front части приложения с сервером, прорабатываются модули и продумывается система безопасности ресурса. Инкрементная модель подходит в тех случаях, когда на старте уже имеется четко прописанное техническое задание, а отдельные изменения понятны, легко формализуются и реализуются. Чаще всего она применяется для разработки продукта, который планируется выпустить на рынок в ближайшее время.
Она подразумевает, что процесс разработки разбивается на повторяющиеся циклы, в каждом из которых продукт постепенно совершенствуется. Для итеративной модели не обязательно наличие на старте четко определенного технического задания и требований. Например, заказчик может определить только базовый набор основных функций, а в ходе последующих итераций дополнять их новыми. Отличие от инкрементной модели состоит в том, что в итерационной дорабатывается весь продукт, а не его отдельные блоки. Смысл в том, чтобы результатом каждого цикла была работающая, пусть и неидеальная, модель.
Бюджет и сроки выполнения проекта и метод разработки связаны и зависят друг от друга. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для её решения вводятся временные ограничения на каждый из этапов жизненного цикла и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена.
Давайте рассмотрим, как проходила разработка реальных проектов, чтобы понять, как эта модель может быть применена. Коротко спиральную модель можно описать как повторяющуюся последовательность циклов разработки с непрерывным контролем рисков. Обычно после релиза ПО в работу подключаются команды техподдержки, которые помогают пользователям с вопросами эксплуатации и следят за стабильной работы своего продукта. Степень риска при разработке ПО варьируется в зависимости от выбранного цикла. При гибком
цикле выше вероятность возникновения неудачных архитектур, но и устранять ошибки проще.
По сути, итеративная модель — это также разновидность инкрементной модели, которая, однако, лучше показывает себя в больших проектах, где конечная цель заранее не определена либо планируется применение каких-либо инновационных подходов. В зависимости от сложности и амбиций проекта разные этапы могут занимать разное время. От этого зависит и выбор методологии, от которой идет обратная зависимость к последовательности и длительности разных этапов.
Для многих решений этот метод неприменим, поскольку из них нельзя вычленить отдельные составляющие, которые могут быть поставлены и функционировать независимо. Индустрия ПО развивается стремительными темпами, однако ни для кого не секрет, что процесс разработки еще очень далек от совершенства и для него характерно множество внутренних проблем. По данным исследования жизненный цикл разработки по Standish Group (), менее третьей части программных проектов оказываются успешными, остальные – либо не вписываются в финансовые и временны2е рамки, либо заканчиваются полным провалом. Инкрементная модель в целом следует той же структуре, что и каскадная, однако, как можно понять из названия, все этапы проходят несколько раз в течение жизненного цикла ПО.
Он подходит для долгосрочные проектов, в ходе разработки которых возникает необходимость в представлении промежуточных версий или внесение изменений и новый требований в ТЗ. Каскадная модель жизненного цикла ПО подходит для выполнения проектов, в которых задействовано несколько крупных команд разработчиков. Линейная структура упрощает управление и формализует взаимодействие участников. V-образная и итеративная пользуются меньшим спросом в силу своей «неуниверсальности». Каскадный цикл разработки ПО требует создания четкого технического задания, практически полностью исключается импровизация, а любые изменения вносятся в договор. Определяется точная стоимость разработки, ориентировочные сроки.
Существует некая вариативность в прохождении этих этапов во время разработки и внедрения продукта. Модели жизненного цикла разработки ПО это описательное представление процесса разработки ПО. SDLC (Software Development Life Cycle, SDLC) могут иметь различные подходы, но основные этапы и действия остаются одинаковыми для всех моделей. Итеративная модель подобно спиральной дает возможность успешно справляться с рисками.
