Часто требуется объяснить новичкам, как построен процесс разработки. Эта статья - разбор последовательности и значения каждого из этапов на примере стройки.

Итак, есть идея: хотим построить дом. Что для этого будем делать?

1. Бизнес-анализ

На этом этапе мы должны как можно лучше понять наши ожидания от нового дома. 

Во-первых, мы должны определиться, где будет построено наше здание. Из вариантов: Desktop, Web, Mobile.

• Разработка Desktop-приложений 

У вас есть собственный земельный участок, и вы будете строить свой дом именно там.

• Web-разработка 

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

• Мобильная разработка

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

Во-вторых, что конкретно мы хотим построить: например, многоквартирный дом, школу или больницу? 

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

В-четвертых, выбрать материалы. Вот, допустим есть Java, она и надежная и кросс-платформенная, можно использовать ее и на front-end, и на back-end. Зачем выдумывать что-то еще? А вот представьте: нужно построить дом, если из материалов на выбор кирпичи и древесина. Что будете использовать? 

Зависит от того, что нужно получить в результате. Если шалаш - то из дерева, если многоквартирный дом - то из кирпича. Каждому материалу свое применение. Можно, конечно, построить и домик на дереве из кирпича, но ветки могут не выдержать.

2. UX/UI разработка

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

На этапе проектирования UХ мы думаем, насколько удобно наше здание в эксплуатации. Хороший UX значит, что мы не заблудился в коридорах, как Семен Фарада из фильма “Чародеи”, сможем добраться ко всем комнатам и не наткнемся на что-то подобное:

Это пример плохого UX.

3. Собственно написание кода

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

Программисты (то есть в нашем случае - строители) бывают 3х типов:  frontend, backend, fullstack. 

Backend занимаются возведением стен, прокладкой коммуникаций, результат их работы - это каркас дома.

Frontend-строительство - это то, что видим по завершении работ. Frontendы возводят внешние стены, красят фасады, вставляют окна, клеят обои, обставляют интерьер и так далее.

В строительстве такие специалисты работали бы последовательно, но разработчики работают параллельно. То есть строится каркас, а кто-то рядом в это время возводит отдельные стены. А потом все как при сборке модульного дома: вставляете стены и мебель в каркас - и готово!

Full-stack - на все руки мастер, он вам и стены возведет, и обои поклеит. Хотя ограничения возможностей все же есть: кто-то сможет построить стены из блоков, но не из кирпичей, а обои будет клеить только виниловые. Ну нельзя же уметь все! А если кто-то утверждает о своей универсальности и берется выполнять и сайты, и мобильные, и веб-приложения, то стоит задуматься. 

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

Оно бывает:

• Модульное. Строители сами прикладывают уровень ко всем поверхностям, таким образом проверяя свою работу

Но в основном обеспечение качества производится тестировщиками - специальной комиссией по приемке работ. Такое тестирование тоже бывает разным:

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

• Стрессовое тестирование. Вы имитируете землетрясение прямо под вашим зданием. Даже если за последнюю тысячу лет землетрясений в радиусе 10000 км не было. Задача - сделать конструкцию устойчивой, как эта арка

• Тестирование безопасности.

• Вы находите двух самых тихих людей на планете, которым очень важно что-то обсудить. Запираете их в одной из комнат, а потом стараетесь найти способ их услышать.Вы должны попробовать все: простучать стены, заглянуть в щели, окна, пролезть вентиляционные шахты. Если услышать разговор не получается  - значит, конструкция безопасна.

• Методом черного ящика

  У комиссии нет понятия о слабых местах системы, но очень хочет их найти, и использует все органы чувств, чтобы найти несовершенства.  

• Белого ящика

  Комиссия наблюдала за работой строителей и отметила слабые места. Инспекторы целенаправленно проверяют именно их. 

5. Непрерывная доставка

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

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

И это почти конец нашей статьи. Осталось маленькое но:

6. Гибкие методологии 

Если вы следуете вышеописанным этапам в разработке ПО, то вы работаете по каскадной модели. Это означает выполнение всех этапов по очереди для всего проекта: то есть сначала весь анализ и проектирование, потом весь дизайн, потом всё строительство, в конце полное тестирование. Но большинство компаний работает по гибким методологиям. Мы делаем все то же самое, но не с целым зданием сразу, а с каждым этажом по отдельности.

Представьте, что вы решили построить 100-этажное здание, но когда был закончен 3 этаж, передумали. Вы больше не хотите небоскреб, а хотите 3-этажный дом с садом на крыше. Что ж, легко! В течении следующего месяца разобьем сад на крыше, а про 4й этаж и остальные 96 благополучно забудем. 

Это изменит стоимость разработки, определенную вначале, в данном случае - в меньшую сторону. Но заказчик может внезапно потребовать сад вместо 4-ого этажа, или - вертикальный, потому что это вошло в тренд в прошлом месяце. Возможно, в строительстве такое случается редко, но в разработке ПО “мода” имеет очень большое значение. Поэтому компании не любят соглашаться на проекты “под ключ” (fixed-price) с фиксированной стоимостью, работают по модели “Time&Mateials”, оплачивая затраченные разработчиками ресурсы. 

Но модели сотрудничества - это уже совсем другая история, о них в следующий раз;)

P.S. Все термины и названия профессий приведены в упрощенном виде для улучшения понимания. Автор не стремился уменьшить роль, ответственность или сложности какой-либо профессии в ИТ.