Продолжаем изучать основы, начало здесь.
Сейчас я хочу рассказать о том, как появляется программное обеспечение, какие этапы и шаги должны быть пройдены для создания рабочего продукта.
Цикл разработки ПО - путь от создания идеи до поддержки готового продукта:
Идея - Дизайн и документация- Кодирование - Тестирование - Релиз.
Идея - описание цели, дизайн - описание пути к достижению этой цели.
После того как написанный код интегрирован, наступает стадия тестирования. Происходит тест приемки (проверяются основные функциональности). Например, если разрабатывается сайт интернет-магазина, то условно тест приемки - найти товар, положить в корзину, оплатить и оформить доставку. Если продукт не проходит тест приемки, нет никакого смысла его тестировать дальше. Если тест пройден, код замораживается, и начинается тестирование новых компонентов (тестирование по написанным тест-кейсам). Далее следует регрессионное тестирование (чтобы удостовериться, что компоненты, которые работали раньше, всё ещё работают). После этого происходит тест сдачи.
Перед началом тестирования тестировщику необходимо удостовериться, что код заморожен, версия продукта соответствует версии, подлежащей тестированию.
После этого происходит релиз.
Релиз - передача пользователям кода новой версии разработанного ПО. Обозначается целыми числами, например, 10.0.
Дополнительный релиз - плановый выпуск новой функциональности или изменения/удаления старой. Обозначается десятыми числами, например, 10.3.
Заплаточный релиз - выпуск программного обеспечения после обнаружения и устранения бага. Обозначается сотыми числами, например, 10.3.1.
Beta-релиз - релиз для представителей целевой аудитории, которые протестируют выпущенное ПО.
А сейчас остановимся на распространенных моделях разработки ПО. Стоит отметить, что выбор той или иной модели зависит от масштаба и сложности проекта, доступных ресурсов и пр.
1. Каскадная (водопадная) модель предполагает однократное выполнение каждой из фаз проекта, которые строго следуют друг за другом. Тестирование проявляется лишь с середины проекта (на этапе разработки и отладки), достигая своего максимума в самом конце. У каждого этапа есть четкий срок выполнения, и в результате его выполнения должен быть достигнут определенный, заранее известный результат. Исходя из этого, у этой модели можно выделить два существенных минуса: 1) неспособность в процессе разработки оперативно вносить изменения и 2) рабочий продукт появляется спустя длительное время.
2. V-образная модель. Усовершенствованная каскадная модель. На каждом этапе происходит контроль текущего процесса, чтобы убедиться в возможности перехода на следующий уровень. Тестирование появляется на самых ранних этапах, и это обстоятельство значительно минимизирует риски. Каждому этапу разработки соответствует свой уровень тестирования. Тут так же, как и у каскадной модели у каждой стадии есть четкий срок и проверяемый результат, но тестированию внимание уделяется с первых этапов. Если у проекта стабильные требования, это модель разработки подходит идеально. Отсюда и главные минусы: недостаточная гибкость и адаптируемость. Если на самых ранних стадиях разработки была допущена и/или не замечена ошибка, ее устранение будет дорого стоить компании.
3. Итерационная инкрементальная модель. Фундаментальная основа современного подхода к разработке ПО. Итерационная, потому что происходит многократное повторение одних и тех же стадий. Инкрементальная, постоянное приращение полезных функций. Проект разбивается на итерации, включающие в себя все этапы каскадной модели, итог итерации - приращение (инкремент) новой функциональности, выраженной в промежуточном билде. Другими словами, вместо одной продолжительной последовательности действий жизненный цикл продукта разбит на несколько мини-циклов. В каждом мини-цикле (итерации) разрабатывается отдельный компонент системы, который добавляется к уже ранее созданному функционалу. Тестирование начинается в определенные моменты итераций, постоянно происходит повторное тестирование. Из этого описания становятся очевидными плюсы этой модели: 1) спустя непродолжительное время выпускается рабочий продукт; 2) несколькими итерациями проще управлять, чем одним большим проектом. Но в то же время внутри итерации процесс недостаточно гибкий, и если допущена ошибка на ранней стадии развития проекта, исправить её будет достаточно сложно.
4. Спиральная модель. Частный случай итерационной инкрементальной модели, а точнее объединение её с каскадной моделью. Выделяются 4 ключевые фазы: а)проработка целей, альтернатив и ограничений; б)анализ рисков и прототипирование; в)разработка(промежуточной версии) продукта; г)планирование следующего цикла.
Жизненный путь разрабатываемого продукта изображается в виде спирали, которая начинается на этапе планирования и раскручивается с прохождением каждого нового шага. На выходе из очередного витка получается готовый протестированный прототип, дополняющий существующий билд. Большое внимание уделяется возможным рискам, связанным с бюджетом, сроками, наличием требуемых специалистов и пр. Эта модель разработки в отличие от предыдущих обладает достаточной гибкостью, но является достаточно дорогой в использовании. Для проектов, где требования сложные и нестабильные, это хороший вариант.
5. Гибкая модель (agile). В основе гибкой модели разработки лежат подходы, являющие лучшей выжимкой из каскадной, v-образной, итерационной инкрементальной моделей разработки. Это совокупность различных подходов разработки, базирующаяся на agile-манифесте.
4 ценности agile:
1) Люди и их взаимодействие важнее процессов и инструментов. Чтобы люди работали эффективнее, инструменты и процессы не должны их ограничивать, более того люди сами решают, как использовать эти инструменты и процессы. Чтобы ускорить процесс люди должны общаться вживую без посредников в виде документов.
2) Работающий продукт важнее исчерпывающей документации. Чтобы клиенты были довольны и пользовались рабочим продуктом, разработчики должны фокусироваться на том, чтобы продуктом как можно скорее можно было воспользоваться, а не на составлении схем, диаграмм и прочего. Чтобы укладываться в сроки часто ведением документации можно пренебречь.
3) Сотрудничество с заказчиком важнее согласований условий контракта. Часто во время разработки появляются новые данные и приоритеты, поэтому важно отказаться от излишних деталей в контракте и создать условия для плотного общения разработчика с заказчиком.
4) Готовность к изменениям важнее, чем следование плану. И заказчик, и разработчик должны быть готовы к внесению возможных изменений на любой стадии разработки, даже на самых последних этапах.
Исходя из этих 4-х положений становится понятно, что при гибкой модели разработки заметно снижается бюрократическая составляющая и достигается максимальная адаптация к мгновенным изменениям рынкам требований заказчика.
Более подробно поговорим об аджайл в следующий раз.
