Code and fix модель кодирования и устранения ошибок

— 1-й
шаг – написание программного кода

— 2-й
шаг – поиск и устранение ошибок в коде

— Принятие
решения о переходе либо не переходе к
стадии концепции

Преимущества
такой модели:

—
может применяться для маленьких программ
(менее 10 000 строк кода)

Минусы:

—
после нескольких исправлений ошибки
могут быть не исправлены;

—
результат очень часто не соответствует
требованиям пользователя;

—
ошибки сложно исправлять из-за отсутствия
тестовых (контрольных) задач/примеров.

9. Модель водопада. Стадии, преимущества, недостатки.

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

Стадия
анализа и определения требований

  • На
    основе «Определения» заказчиков
    создаются «Пользовательские требования»

  • На
    основе «заданных определений» к ПО
    разрабатываются требования к ПО

  • Результатом
    является Системная спецификация
    (требования к системе) – пользовательские
    и функциональные требования к ПО

Стадия
проектирования ПО

  • Определяются
    требования со стороны используемых
    аппаратных и программных систем

  • Система
    делится на модули – создается архитектура
    системы

  • Определяются
    требования и спецификации модулей и
    требования к их взаимодействию

  • Разрабатывается
    детализированная спецификация –
    содержит структуру и архитектуру
    модулей.

  • Результат:
    документация по архитектуре системы,
    детализированные спецификации на
    модули — документы, подробно описывающие
    для программистов способ и план
    реализации указанных требований +
    тестовые примеры.

Реализация
и тестирование компонентов

  • Разрабатываются
    модули по отдельности

  • Выполняется
    тестирование модулей (Test Frame). Тесты
    включают функциональные тесты

Стадия
интеграции и системного тестирования

  • Объединение
    модулей (интеграция)

  • Тестирование
    объединенных модулей – «интегрированное
    тестирование»

  • Проверка
    соответствия требованиям пользователей
    и системным требованиям

  • В
    случае успешного прохождения всех
    тестирований и проверок – продукт
    предоставляется заказчику

Внедрение
и поддержка

  • Функционирование
    и поддержка

  • Установка
    у заказчика, «разрешение» на использование

  • Исправление
    не выявленных ранее ошибок и недочетов
    (может оказаться очень дорогим)

  • «Улучшение
    поведения» системы – например запуск,
    графический интерфейс пользователя и
    т. п.

  • Расширение
    системы – внедрение новых функций
    (если необходимо)

Преимущества

  • Программа
    и цикл ее разработки хорошо структурирована
    и задокументирована

  • После
    каждой стадии поддерживаются
    управленческие решения

  • Благодаря
    четко определенным требованиям
    достаточно просто передавать разработку
    субподрядчикам

Недостатки

  • Требования
    и спецификации фиксируются раз и
    навсегда – результат может не
    соответствовать потребностям заказчикам

  • Возможны
    сложности при разработке интерактивных
    продуктов из-за того же – фиксации
    требований и функций на ранних стадиях

  • Точка
    зрения заказчика фактически приравнивается
    к точке зрения разработчика – проблема
    в том, что заказчик может четко сказать,
    что он хочет, только получив результат

10.
V-образная модель.

Используется
для определения единой процедуры
разработки программных продуктов,
аппаратного обеспечения и человеко-машинных
интерфейсов. V-Model (VEE) представляет собой
скорее набор стандартов в области
проектов, касающихся разработки новых
продуктов.

Идея
модели:

  • Разработка
    привязана к организации тестовых
    примеров

  • Чем
    дольше ошибки присутствуют в системе,
    тем дороже их устранение

  • За
    стадиями конструирования должны
    следовать стадии тестирования

  • В
    целом процесс аналогичен модели водопада

Особенности:

  • Показывает
    связи между каждой фазой ЖЦ

  • Каждая
    фаза может быть реализована на основе
    детальной документации по предыдущей
    фазе

  • Фактически
    расширение водопадной модели

Преимущества:

  • Считается
    хорошо проверенной (в Германии) и
    подходящей для большинства проектов

  • Тестирование
    может начинаться с анализа требований
    и определения критериев – что собственно,
    нужно тестировать

Недостатки:

  • Ошибки,
    найденные позже стадии абстрактной
    модели, гораздо дороже в обнаружении
    и устранении

Соседние файлы в предмете Управление проектами

  • #
  • #
  • #
Источник

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

Что такое модель разработки продукта и для чего она нужна

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

  • Планирование. Определяем, что делаем и какие проблемы решаем. Ставим цели, выясняем, какие ресурсы нам нужны для реализации проекта. Изучаем рынок и конкурентов, прорабатываем альтернативные варианты разработки продукта.
  • Анализ системы. Определяем и документируем требования конечного пользователя системы. Какие ожидания есть у нашего потребителя и как мы можем их осуществить? Можем ли мы это сделать вообще?
  • Дизайн. Определяем элементы системы, ее компоненты, уровень безопасности, архитектуру, интерфейсы, типы данных. Рисуем дизайн, обсуждаем, проектируем.
  • Разработка и внедрение. К началу этой стадии дизайн уже завершен, наступает очередь разработки. Пишем код, настраиваем систему под определенные требования и функции. К концу фазы система готова к установке и запуску.
  • Тестирование. Проверяем, получили мы в итоге то, что хотели, или же результаты работы оказались другими. Тестируем продукт автоматизированными тестами, командой, предлагаем поработать с системой потенциальным пользователям. Определяем дефекты и недостатки в работе системы и устраняем их.
  • Поддержка системы. Подготовка и выпуск обновлений, оценка производительности системы, замена/деактивация устаревших компонентов.

Это классическая схема, которая изменяется в зависимости от того, каким образом идет разработка, а также от специфики работы команды, размера бюджета и особенностей продукта. Именно здесь и наступает момент выбора модели разработки. Они подразделяются на классические и гибкие.

Вот список классических моделей:

  • Code and Fix (написание кода, проверка и устранение ошибок),
  • Waterfall (проект последовательно проходит все стадии),
  • V-Model (проведение тестирования одновременно с разработкой),
  • Инкрементная модель (проект делится на составные компоненты, команда по очереди готовит каждый из них, затем происходит финальная сборка),
  • Спиральная модель (предусматривает тщательную проработку рисков),
  • Итеративная модель (сначала делается базовая модель продукта, затем следуют итерации по ее усовершенствованию),
  • RAD-Model (скоростная разработка продукта).

Классические модели предполагают акцент на последовательности, сроках, конечных требованиях к продукту.

Что касается гибких моделей, то это всем известный Agile. Когда мы работаем над продуктом по гибкой модели, наш проект и требования к нему могут меняться в течение каждой итерации (гибкая модель, когда проект может изменяться с каждой итерацией), а что касается сроков, то работа может вестись бесконечно — вы будете совершенствовать продукт и добавлять в него новый функционал.

Наконец, методологии разработки — это применение той или иной модели на практике. Так, Agile-модель имеет целый ряд довольно популярных методологий — от мягкого Kanban, когда команда работает с доской с задачами, до жестких Scrum и XP.

Теперь рассмотрим особенности каждой из упомянутых моделей.

Code-and-Fix

Это одна из самых старых моделей разработки: она очень проста и подойдет стартапам, где команда невелика, нет особых конфликтов, вы знаете, что хотите сделать и имеете представление, как это сделать.

Как работает Code-and-Fix: у нас есть понимание, что мы хотим сделать. Начинаем программировать, затем смотрим, что получилось. Выявляем баги, правим их и снова смотрим — и так, пока наш продукт не начнет работать.

Плюсы методологии: не нужно тратить время на планы, документацию, митинги.

Минусы: иногда исправление одной ошибки приводит к тому, что у вас ломается вся система. В итоге приходится переделывать — снова и снова. Поэтому когда-то давно программисты, которые мучились с этой моделью разработки, решили уйти от ее мнимой простоты и изобрести другую.

Waterfall

Одним из первых выходов стал Waterfall, или водопадная (каскадная) модель разработки. Это классическая жесткая модель: у вас есть план, бюджет и вы строго выполняете этап за этапом.

Разработка продукта идет по ступенькам: вы изучаете требования, проектируете продукт, разрабатываете его, тестируете и затем поддерживаете его работу. Новый этап не начинается, пока не завершится предыдущий. Ошибки, допущенные на этапах изучения требований и проектирования, очень сложно исправить — как в финансовом плане, так и в техническом — и это самая большая проблема этой модели.

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

Когда используется водопадная модель

Эта модель используется при разработке программ для строительства, медицины, работы с государственными контрактами. Если говорить о непрограммных продуктах, то каскадная модель применяется для строительства крупных объектов.

Емко этот метод описал Чак Кобб, автор книг по проектному менеджменту:

Если бы вы строили мост через реку, было бы смешно сказать: «Мы построим первый пролет, посмотрим, как это выходит, а затем решим, как закончить оставшиеся пролеты!”

Действительно, в таких объектах должен быть заранее утвержденный план, макет, прототип, и изменения, как правило, не предусматриваются.

Каскадную модель применяли: компания Cisco для разработки систем безопасности, IBM, Microsoft IT и даже Toyota.

V-Model

V-Model — улучшенная версия водопадной модели. В отличие от последней V-model предполагает тщательную проверку и тестирование продукта уже на ранних стадиях разработки — оба процесса идут параллельно. При переходе на следующий этап разработки предусмотрен контроль всего, что было сделано до этого. Все найденные ошибки устраняются, и только затем наступает новая фаза работы над продуктом.

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

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

Инкрементная модель

Эта модель разработки дает возможность делать продукт по частям — инкрементам. Каждая часть представляет собой готовый фрагмент итогового продукта, который в идеале не переделывается.

Мы получаем несколько циклов разработки — своеобразный “мультиводопад”. Каждый цикл делится на модули, каждый модуль — на фазы: определение требований, проектирование, написание кода, внедрение, тестирование.

Такая модель позволяет проработать риски и вывести базовую версию продукта на рынок, когда весь запланированный функционал может быть еще в стадии проектирования. Стартапы могут ее использовать, если у них есть общее понимание, каким должен быть их продукт в итоге.

Спиральная модель

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

Для разработки продукта по спиральной модели часто проводятся специальные научные исследования и аппробации.

Разработка идет по спиралям, каждая из которых состоит из четырех основных этапов: планирования, анализа рисков, конструирования, оценки результатов.

Спиральная модель довольно затратна в применении, поэтому не подходит для небольших проектов. А вот для средних и больших ее можно применять, особенно, если вы боитесь прогореть.

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

Кейс GanttPRO. Приложение для управления проектами и задачами GanttPRO разрабатывалось по принципам спиральной модели, а также фреймворка Agile — Scrum, о котором расскажу чуть ниже. Разработчики выбрали довольно короткие двухнедельные периоды релизов для того, чтобы иметь возможность часто получать отзывы. Также был создан детальный план того, что должно было быть реализовано на первой итерации и как проработать различные риски. Например, перед первой итерацией каждый разработчик высказался по поводу того, что из запланированного может не быть реализовано и почему. Кроме того, команда уделила особое внимание снижению рисков, вызванных необходимостью быстрой адаптации к нуждам пользователей и рынка.

Итеративная модель

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

Итеративную модель можно сравнить с картиной, когда сначала мы рисуем некий набросок, исходя из которого можно увидеть, что будет изображено. С каждым шагом мы добавляем новые цвета и переходы. В итоге получаем готовую картину. А в случае стартапа — готовый продукт.

Модель подходит для стартапа, который хочет как можно быстрее выйти на рынок и привлечь клиентов.

Кейс “Самокат”. Метафорически итеративную модель можно проиллюстрировать на примере разработки транспортного средства. Результатом первой итерации может стать самокат. Это пример транспорта, хоть и максимально простого. Результатом второй итерации может стать самокат с электродвигателем, третьей — электровелосипед, четвертой — мотоцикл. Таким образом, с каждой итерацией повышаются функциональные возможности продукта, созданного еще во время первой итерации. Сравним разработку этого же транспортного средства по водопадной модели: траспорт мы получим в самом конце, после того, как будут завершены все стадии проекта.

RAD-Model, или Rapid Application Development Model

Разновидность инкрементной модели. Появилась в конце 80-х годов и стала одной из попыток создания гибкого процесса разработки.

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

Плюсы такой модели разработки — скорость. Минусы — финансирование.

Agile

Гибкая модель разработки, по которой сегодня работает большинство ИТ-проектов. Вы получаете определенный результат после каждой итерации, можете вносить изменения в первоначальное видение продукта практически в любой момент работы — исходя из того, какой функционал больше нравится пользователям вашего продукта.

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

Agile имеет множество вариаций и фреймворков. Среди самых известных: Scrum, Kanban, экстремальное программирование (XP), Lean.

Kanban

Является одной из методологий Agile. Метод базируется на концепции бережливого производства, основанной на стремлении к устранению всех потерь — временных, производственных, логистических, качественных.

Особенность Kanban — задачи должны выполняться точно в срок, нагрузка между командой распределяется равномерно.

На практике это выглядит следующим образом. Каждая задача по проекту описывается в отдельной карточке и добавляется на доску — виртуальную или настоящую. Карточка и доска — неотъемлемые элементы Kanban. Все задачи, которые необходимо сделать, собраны в специальной колонке, условно, она может называться “сделать”/ “to do”. Исполнитель выбирает задачу и перемещает в колонку “в процессе” / “in progress”. Когда задача сделана, она попадает в соответствующую колонку “готово” / “done”. На практике колонок может быть гораздо больше, чем три. К примеру, колонки на доске могут выглядеть так: “обсуждается” (backlog), “согласовано” (ready), “кодируется” (coding), “тестируется” (testing), “подтверждается” (approval) и “сделано” (done).

Кейс “Тойота”. Методология Kanban родилась на производстве в компании Toyota. Мастера участков перечисляли выполняемые работы на бумаге и вывешивали их на видном месте — так и родилась доска канбан, один из элементов методологии. В основе производства Toyota — годовой план производства и сбыта авто, на базе которого составляются месячные и оперативные планы среднесуточного выпуска на каждом участке, основывающиеся на прогнозировании покупательского спроса. Методология базируется на принципе “точно в срок”, что, помимо четкого следования таймингу по каждой задаче, позволяет раскрывать дефекты производства вовремя. Например, ежедневные контроль запасов продукции и деталей выявляет неисправности или простои.

Scrum

Одна их самых популярных методологий Agile. В отличие от канбан, у скрама гораздо больше элементов — различные митинги (от ежедневных пятиминутных, до планирований спринтов, демо), четкое разделение по ролям. Кроме того, разработка подразделяется на спринты — которые длятся от недели до четырех недель и заканчиваются выпуском части продукта.

В переводе с английского scrum — это драка либо схватка вокруг мяча. Термин пришел из регби и означает специфическую игровую ситуацию, в которой участники команд смыкаются в три линии с каждой стороны, когда в игру вводится мяч после нарушения правил; задача игроков — выиграть за счет совместных усилий команды.

Почти так же применяется методология Scrum при разработке ПО: команда кросс-функциональных специалистов совместно реализует проект. Важно, чтобы это были профессионалы с высокой мотивацией, инициативные и готовые вносить изменения как в ход реализации проекта, так и в продукт.

Рассмотрим пример применения Scrum.

1. На этапе формирования продукта вы с командой решаете, кто из вас будет исполнять роль product owner — человека, который отвечает за связь команды с потребителем и инвесторами (если ваши инвесторы будут интересоваться ходом разработки продукта).

2. Product owner формирует список пожеланий к продукту, собирает первичную информацию от возможных пользователей и затем формирует бэклог продукта — список задач, выполнение которых в конце концов приведет вас к выходу на рынок.

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

4. В течение первого спринта вы отслеживаете качественные и количественные характеристики своей работы. Неотъемлемая часть скрама — ежедневные короткие (5–10) минут митинги, в течение которых каждый из участников команды рассказывает, что он планирует сделать за день, делится возникающими сложностями или, наоборот, успехами.

5. Ход выполнения задач отслеживается по скрам-доске, на которой все задачи двигаются от условной позиции “сделать” до “выполнено”.

6. По завершении спринта вы демонстрируете выполненную часть работы и собираете обратную связь — от членов команды, клиентов, в т.ч. потенциальных.

7. Цикл спринтов повторяется до того момента, пока продукт не будет полностью завершен.

Экстремальное программирование (XP)

eXtreme Programming, экстремальное программирование, XP — гибкая методология разработки, которая появилась в конце 90-х годов прошлого столетия. Авторы взяли лучшие, на их взгляд, практики гибкой разработки и усилили их до максимума — отсюда и слово “экстремальный” в названии.

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

Особенностью XP являются некоторые практики, самая известная из которых — парное программирование. Суть его заключается в том, что два разработчика одновременно работают над кодом для одной функции продукта: сначала один пишет, а второй наблюдает и исправляет ошибки, затем они меняются местами. Таким образом, в процессе создания кода есть два альтернативных решения, на каждом этапе выбирается лучшее. Парное программирование работает по принципу: одна голова — хорошо, а две лучшею

Другая особенность экстремального программирования заключается в том, что сначала готовятся тесты, и только потом — код. При этом тесты пишут сами программисты. Тестирование позволяет исправить большинство ошибок на стадии создания кода.

Третья особенность — коллективное владение кодом: каждый программист в команде имеет доступ к коду продукта и может вносить в него изменения. В том случае, если изменения привели к некорректной работе системы, исправить все должен тот программист, который внес эти изменения.

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

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

Lean

Lean Software Development, или бережливая разработка программного обеспечения — гибкая методология, основанная на концепции бережливого производства. Среди принципов методологии — исключение потерь (к ним относится все, что не добавляет ценности для потребителя — излишняя функциональность, паузы в процессе разработки, нечеткие требования и пр.); акцент на обучении (предполагаются короткие циклы разработки, раннее тестирование), принятие решений на основе фактов, мотивация команды.

Выводы

Как видим, даже если вам кажется, что вы работаете “без заморочек” — без всяких там методологий и прочего — на самом деле даже это прописано в теории:) Скорее всего, вы работаете по модели Code-and-Fix и, возможно, уже совсем скоро столкнетесь со всеми ее недостатками. Чтобы их избежать, важно перед началом работы над продуктом проанализировать его и вместе с командой, решить, по каким фазам будет идти разработка. Оптимальный вариант выбирается, исходя их того, сформировали вы уже конкретные требования к своему продукту или планируете “совершенствовать” его во время работы; какой у вас бюджет и насколько кросс-функциональна команда; насколько длителен проект по времени выполнения и как обстоят дела с финансированием.

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

Автор статьи: Надежда Юшкевич

Startup Jedi создается при поддержке Rocket DAO. Здесь вы можете изучить проект.

Источник

Онтогенез повторяет филогенез

—биогенетический закон

Да, вы не ошиблись, это еще одна из огромного множества статей,
посвященных соотношению плановости и гибкости при разработке
программного обеспечения. Поэтому эта статья — не более чем авторский
пересказ уже не раз высказанных идей. Но, как известно, украденное у
одного — плагиат, украденное у троих (и более) — научный труд. Так
что знайте: вы читаете научный труд.

/media/images/simplicity.jpg

Кажущаяся простота

Статья состоит из трех частей.

Первая ее часть посвящена классике. Я расскажу об истории развития
методологии разработки ПО, какие возникали задачи, какими методами
они решались. Вы увидите, что в классике можно решить гораздо больше
проблем, чем это пытаются представить фанатики «гибких» разработок.

Вторая часть статьи посвящена «гибким» методикам. В ней я расскажу об
историческом контексте возникновении этого течения. Я расскажу об
основных его идеях и сравню этот подход с классическим.

Наконец, в ее третьей части я остановлюсь на проблемах «гибких»
методик. Я покажу, как по мере взросления продукта в его разработку
приходится вносить все больше элементов классики: планирования,
документирования…

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

Итак, в этой статье:

  • Зачем безопаснику SDLC
  • История, классика
    • Code-and-Fix
    • Водопад
    • Поэтапная поставка
    • Прототипы
    • Спиральная модель
    • Качество и архитектура программы
    • Классика классики: RUP
  • Рождение «agile»
    • Пузырь доткомов
    • Agile Manifesto
    • Гибкость против плановости
    • Поддержание качества кода
  • Проблемы роста
    • Квалификация разработчиков
    • Время и память
    • Магические «7±2»
    • Территориальная разъединенность
    • Разрешение конфликтов
    • Требования к качеству
  • Заключение
  • Постскриптум
  • Литература

Зачем безопаснику SDLC

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

Зачем же им тогда читать эту статью?

Многие из нас (безопасников) так или иначе имеют опыт взаимодействия с
разработчиками. Кому-то приходилось писать требования безопасности,
кому-то — проверять их выполнение, делать сертификацию, кто-то еще
столкнется с этими задачами. Иногда бывает полезно понимать возможности
компаний, предлагающих нам свои продукты, просто для того, чтобы
сделать наилучший выбор.

Проектирование и/или выбор программы — задача не самая простая.

Любой программный продукт — результат целого ряда компромиссов. Как мы
знаем, существует целый ряд свойств, характеристик программы; назову
только некоторые из них: функциональность, быстродействие, удобство
использования и, конечно, безопасность. Также мы знаем, что
безопасность часто противоречит другим свойствам продукта, например,
его функциональности, его быстродействию. Немаловажно и то, что
обеспечение безопасности программы требует дополнительных проектных
ресурсов: и времени, и денег.

Методы обеспечения безопасности объективно мешают разработчикам. И,
естественно, они — со своей позиции — отстаивают интересы развития
проекта. «Геннадий! Вы не понимаете!» — эти слова мне приходилось
слышать не раз и не два за время, когда я консультировал разные
группы.

Приходится находить с ними общий язык. Поэтому знание того, как
разрабатывается ПО, какими методами достигаются разные свойства
программы, является очень важным и для безопасника. О важности этого
знания косвенно свидетельствует и то, что (ISC)2 включила
«Software Development Security» в список 10 ключевых областей, в
которых обязательно должен разбираться специалист для успешного
прохождения сертификации CISSP.

Поэтому я надеюсь, что статья будет безопасникам и интересна, и
полезна.

История, классика

Начнем с классики.

Давайте договоримся отнести сюда все методы, которые
противопоставляются «гибким». Я буду называть их классикой, вы можете
встретить и другие их названия: плановые методы, упорядоченные
(disciplined) методы.

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

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

Code-and-Fix

Исторически, первой моделью разработки программного обеспечения была
Code-and-Fix (см., например, [Boehm1988] или [McConnell1996]).

Используя Code-and-Fix, мы только пишем код.

Описать правила этого метода просто:

  • получаем начальное понимание потребностей заказчика;
  • начинаем программировать;
  • когда что-то будет готово, показываем «это» заказчику;
  • получив отзывы, исправляем наш код;
  • повторяем цикл до полного удовлетворения заказчика (или пока у него
    не кончатся деньги, терпение…)

Используя Code-and-Fix, мы только пишем код. Здесь все очень просто:
нет необходимости что-либо планировать, нет необходимости что-либо
документировать. Поэтому Code-and-Fix требует минимальной квалификации
разработчиков, соответственно, им можно платить меньше денег.

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

Все последующее развитие методик разработки выросло из стремления решить
эти проблемы.

Водопад

Водопад стал первым решением проблем code-and-fix.

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

Я думаю, все более или менее знакомы с этой моделью, поэтому обращу
внимание только на некоторые особенности.

Простая водопадная модель. Рисунок взят из Виккипедии.

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

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

Поэтому давайте обсудим их чуть подробнее.

Первый этап — разработка требований. В ходе этого этапа программа
представляется в виде абстрактного описания функциональности. Причем
«требования» должны быть полностью независимыми от технологий, которые
будут использованы в реализации. Необходимость абстрактности в этом
случае понятна, ведь выбор технологий — это уже следующий этап.

Существует несколько ситуаций, в которых первый этап может быть
успешен.

Одна из таких возможностей — наличие опыта эксплуатации информационной
системы, очень похожей на разрабатываемую нами (см., например,
[Pohl2010]). Интересно, что такой — образцовой — информационной
системой не обязательно должна быть компьютерная система. Десяток
бухгалтеров со счетами тоже могут представлять основу для разработки.
Главным условием является наше понимание происходящих в системе
процессов.

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

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

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

Достоинства и недостатки

Водопадная модель оказалась очень удачной. Она настолько хорошо решила
проблемы Code-and-Fix, что Министерство Обороны США потребовало, чтобы
все программные проекты, выполняемые в ее интересах, использовали
только эту модель.

Не потеряла она свою актуальность и сейчас. В тех случаях, когда модель
водопада применима, у нее есть целый ряд достоинств (см., например,
[McConnell1996]).

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

Во-вторых, требования к квалификации программистов снижены. Только
этапы проектирования требуют наличия высококвалифицированных
специалистов, реализация может осуществляться начинающими
программистами. Поскольку реализация требует больших временны́х
затрат, то это свойство позволяет существенно снизить
потребность в высококвалифицированных специалистах.

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

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

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

Приведу основные из них.

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

Во-вторых, в огромном количестве проектов возникают проблемы с
формулированием требований на раннем этапе разработки.
Причин для этого бывает множество:

  • заранее сформулировать требования может далеко не каждый
    заказчик;
  • даже если он сможет это сделать, он сделает это на своем
    языке, который отличается от языка разработчиков;
  • при формулировании и переформулировании требований — например, с языка
    заказчика, на язык разработчика — всегда будут
    допускаться неточности, будут опущены некоторые, иногда очень
    важные, детали;
  • предположение о том, что требования не зависят от архитектуры
    системы не всегда верно (см., например, [Ralph2013] и
    [Swartout1982]).

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

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

Водопад в современном мире

Несмотря на плохую славу, водопадная модель жива и сейчас.
Практически только водопад применяют для создания программ, к качеству
которых предъявляются высокие требования: авионика, системы управления
критическими производствами, высококачественные системы информационной
безопасности. Я даже думаю, что водопад мог бы применяться чаще, если
бы не его плохая репутация.

Модель не только жива, модель развивается. Хотя, казалось бы, в нее
уже нечего добавить, в начале 2000-х годов была создана V-model,
дополнившая водопад процессами валидации и верификации. И именно этот
вариант часто применяется при разработке высоконадежных программ.

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

Поэтапная поставка

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

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

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

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

Вспомним, после завершения высокоуровневого проектирования
все модули могут разрабатываться и реализовываться независимо.

Воспользуемся этой независимостью. Давайте спроектируем нашу систему
так, чтобы существовали отдельные модули, которые несут самую
необходимую клиенту функциональность; при этом они должны быть
относительно независимы от других частей программы. Давайте теперь
реализуем эти модули в первую очередь, а вместо других
поставим «заглушки». Очевидно, мы можем в этом случае начать поставки
сразу по готовности «срочных» модулей.

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

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

Прототипы

Итак, для успешной разработки с использованием водопадной
модели или по модели поэтапной поставки, мы должны иметь:

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

Все это у нас есть — можем использовать водопадную модель. А что же
делать, если у нас нет такого опыта?

Надо его приобрести!

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

Идея использования прототипов даже в программировании далеко не нова.
Еще в своей основополагающей статье ([Royce1970]), Ройс предлагал
не ту водопадную модель, которая стала потом классикой. Он предлагал
разрабатывать систему дважды! Первый раз — прототип, и только затем
— готовую программу.

С тех пор прототипы получили огромное распространение. Было
предложено множество способов их создавать, множество способов их
использовать. И, конечно, понадобилась возможность во всем этом
многообразии разобраться, классифицировать прототипы.

Как и самих прототипов, есть много способов их классификации (см.,
например, [Carr1997]). Прототипы рабочие или «на выброс», прототипы
для показа клиенту или для внутреннего использования, прототипы
горизонтальные или вертикальные. Я воспользуюсь только одной из
возможных классификаций, предложенной Флойдом еще в 1984 году
([Floyd1984]). Согласно этой классификации, существует три типа
прототипов, различающихся по назначению: исследовательский,
экспериментальный и эволюционный.

Такая классификация весьма условна. Мы можем начать с
исследовательского прототипа, а он плавно перерастет в
эволюционирующую версию нашей программы. А может случиться наоборот, мы
начнем делать эволюционный прототип, но будем вынуждены его выбросить
и начать разработку с чистого листа.

Тем не менее, такая классификация полезна для понимания, зачем мы
занимаемся прототипированием.

Исследовательский прототип

Назначение исследовательского (exploratory) прототипа — уточнение
требований к разрабатываемому продукту. Он служит своеобразным языком
общения разработчика и клиента. Для краткости, в этой части, говоря
прототип, я буду иметь в виду именно исследовательский прототип.

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

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

С точки зрения клиента, ценность прототипа в возможности «потрогать»
готовую программу. Он видит, как она выглядит, иногда, как она себя
ведет. Вместо обсуждения абстрактных моделей он может говорить о
конкретной, почти материальной, вещи. Он может сравнить свои фантазии
по поводу создаваемого продукта с возможностями разработчика.

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

Конечно, мы хотим разработать прототип как можно дешевле. Поэтому,
чаще всего исследовательский прототип — вещь одноразового
использования (throwaway), он разрабатывается очень быстро, без
сложных техник, обеспечивающих качество. Для разработки исследовательских
прототипов даже созданы специальные языки программирования,
позволяющие создавать код быстрее за счет некоторого сокращения
проверок. Примером такого языка является модный сейчас Python.

Таким образом, исследовательский прототип является самым простым и
дешевым из рассматриваемых здесь трех типов.

Экспериментальный прототип

Назначение экспериментального прототипа — проверка технологии. Мы
создаем его, чтобы убедиться, что сможем достичь поставленных задач,
используя имеющиеся у нас средства. Если исследовательский прототип
можно сравнить, скорее, с портфолио художника, то экспериментальный
прототип надо сравнивать с уменьшенной моделью самолета, который мы
продуваем в аэродинамической трубе.

Проверять мы можем самые разные свойства программы. Мы можем
тестировать пользовательский интерфейс, быстродействие нашей
программы, возможности реализации выбранного алгоритма на нашем
«железе» и так далее. Любые аспекты выбранных нами технологий, в
пригодности которых у нас есть сомнения, мы можем проверить с
помощью таких прототипов.

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

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

И, конечно, чем больше часть, с которой мы экспериментируем, тем
больше наши риски.

Эволюционный прототип

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

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

И все же, мы рассматриваем эволюционный прототип именно как прототип.
Флойд отмечал ([Floyd1984]), не существует четкой границы между
этим типом прототипа и предыдущими двумя. Действительно,
представим себе, что мы экспериментируем с небольшой частью программы;
это экспериментальный прототип. Мы экспериментируем с программой
целиком — это эволюционный прототип. Какого размера должна быть
часть, с которой мы экспериментируем, чтобы сказать, что это, скорее,
уже программа целиком?

Методология эволюционного программирования развивается уже давно. Формально
она была предложена в 1982 году ([McCracken1982]), а в 1988 году Том Гилб
опубликовал книгу «Principles Of Software Engineering Management»([Gilb1988]),
ставшую классикой и описывающую, кроме всего, Evo метод — метод
эволюционного развития программы. В качестве отступления замечу, Том
Гилб сделал очень многое в области развития методологии разработки ПО. Кроме
всего прочего, он был еще и одним из ведущих разработчиков методологии
инспекций — систематического анализа кода и документации с целью улучшения их
качества. Поэтому его работа в направлении эволюционного программирования заслуживает
самого пристального внимания.

Конечно, у эволюционного программирования есть свои недостатки. Как
отмечает Боэм ([Boehm1988]), при его применении существуют две
опасности:

  • от разработки эволюционного прототипа очень легко — при отсутствии
    достаточного опыта — скатиться к катастрофически проблемному
    code-and-fix;
  • клиент может оказаться не готов воспринять проект, реализуемый без
    плана.

Тем не менее, именно эволюционное прототипирование является
фундаментом современных «гибких» методологий.

И в завершение этой части, стоит сказать, что метод эволюционного
прототипирования является наиболее ярким представителем
итерационной разработки. В отличие от инкрементального,
итерационный процесс предполагает возвращение к уже сделанной работе и
ее улучшение (читай — переделывание). Естественно, цена этому —
повышенная стоимость разработки.

Спиральная модель

Мы видим, что многообразие задач привело к многообразию методов их
решений. Уже в конце 70-х, начале 80-х годов было создано немало
вариаций водопадной модели, предложено большое число способов создания
прототипов, начинали развиваться формальные методы. Каждый из этих
подходов решал одну или несколько проблем, возникающих при разработке
ПО.

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

Эту задачу и решила спиральная модель.

Модель была создана в середине 80-х годов прошлого столетия Барри
Боэмом. В 1986 году он впервые опубликовал описывающую ее статью
([Boehm1986]); сейчас в интернете доступна более поздняя версия этой
статьи ([Boehm1988]). Модель получилась, мягко говоря, не самая
простая, многими она была не понята (как и изначальная водопадная!),
поэтому более чем через десять лет понадобилась еще одна, разъясняющая
публикация ([Boehm2000]).

Свое название модель приобрела из-за выбранного ее автором
представления развития проекта. График затраты-прогресс чертится в
полярной системе координат: по радиусу откладываются ресурсы, уже
затраченные в проекте, угловые координаты отражают достигнутый
прогресс. Таким образом, график выглядит, как разворачивающаяся
спираль. Рисунок, приведенный автором в его статье, стал визитной
карточкой этой модели.

Иллюстрация к спиральной модели из Виккипедии. Иллюстрация
содержит неточности. Можете ли вы их найти?
(Кстати, некоторая яйцеобразность спирали на
картинке присутствовала и в оригинальном изображении, автор
при этом сослался на свободу художника.)

Одна такая спираль — один проект. В каждом проекте тестируется
гипотеза, что планируемый программный продукт может быть создан, или
что в уже существующий продукт может быть внесено некоторое изменение
([Boehm1988]). Если гипотеза верна — мы получаем успешно завершенный
проект, если мы ошиблись — спираль завершается без результата.

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

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

Не все ясно осознают эту идею.

Многие принимают рисунок из статьи Боэма в качестве образца единственно
возможного развития проекта. Это проект, в котором сначала уточняются
требования пользователя, затем проверяется возможность их реализации.
В нем активно используются как исследовательские, так и
экспериментальные прототипы. Завершается этот проект в соответствии с
водопадной моделью.

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

Понимаемая таким образом, спиральная модель является метамоделью для
всех современных процессов разработки программного обеспечения,
включая «гибкие». И, пользуясь ею, можно эффективно управлять
программными проектами.

Впрочем, соглашусь: спиральная модель не слишком проста для понимания.

Качество и архитектура программы

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

Основное свойство программы — ее функции. Именно функции программы,
что она делает, позволяют нам достигать своих целей; именно ради
функций мы покупаем программы; именно ради функций нам, разработчикам,
программы заказывают.

Некоторые нефункциональные свойства программы
могут быть оценены только после определенного времени эксплуатации,
иногда довольно длительного.

Но у любой программы есть и множество других характеристик,
качественных, нефункциональных. Они определяют, как программа
реализует свои функции, какая она. Для этих свойств англоязычные
специалисты даже придумали специальный термин “-ilities”.
Перечислять все нефункциональные свойства можно долго, приведу для
примера только некоторые: быстродействие, удобство использования,
удобство модификации, тестируемость и, конечно, наша любимая
безопасность.

Нефункциональные свойства проявляют себя по-разному. Некоторые из них
очевидны сразу: если программа «тормозит», то мы не будем ее
использовать, несмотря на богатую функциональность. Другие мы сможем
оценить только через длительное время: это и модифицируемость, и
безопасность, и надежность.

Давайте запомним: некоторые нефункциональные свойства программы
могут быть оценены только после определенного времени эксплуатации,
иногда довольно длительного.

Качество программы зависит от ее архитектуры (см., например,
[Bass2012] и [Taylor2009]).

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

Программа запрашивает и проверяет имя и пароль пользователя — это ее
функциональность. Соответствующий код мы можем разместить как на
серверной, так и на клиентской части; функциональность от этого вообще
ни как не изменится, функциональное тестирование вообще не «увидит»
никакой разницы: программа будет и запрашивать, и проверять личность
пользователя. Но — надеюсь, это всем очевидно — от этого выбора будут
зависеть и быстродействие, и безопасность, и много еще чего.

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

Вообще, архитектура программы определяет:

  • части, из которых программа состоит;
  • свойства этих частей;
  • как эти части между собой взаимодействуют.

Приведу примеры архитектурных решений:

  • мы используем реляционную базу данных или храним информацию в
    файлах;
  • мы используем двух- или трехзвенную
    архитектуру;
  • мы пишем нашу программу на Java или C++;
  • мы используем IPSec или SSL.

Иногда определяют еще один уровень абстракции — дизайн программы. Тогда
под этим термином понимается локальная архитектура, архитектура отдельных
частей системы (см., например, [Eden2003]). Понятно, что дизайн, определяющий
свойства отдельных частей, влияет на архитектуру, а через нее — на качество
программы.

Наука об архитектуре и дизайне программ имеет такую же длительную
историю, как и вся технология их разработки. Желающих подробнее
познакомится с этой историей, я отсылаю к
введению в сборник «Software architectures — advances and
applications» ([Barroca2000]).

Я же очень коротко упомяну важнейшие достижения в этой области.
Конечно, здесь обязательно надо сказать об абстракциях, поддерживаемых
компиляторами: подпрограммах, модулях, объектах. Здесь же надо вспомнить
о лучших практиках построения программ — образцов дизайна; книга
«банды четырех», посвященная этой теме ([Gamma1995]), стала классикой
и почти обязательным чтением для всех уважающих себя программистов. И
здесь же надо упомянуть лучшие практики построения архитектуры
системы: тактики и образцы архитектуры (см. уже упоминавшиеся
[Bass2012] и [Taylor2009]).

Сейчас мы понимаем, что не можем сделать идеальную программу (пока
или вообще?). Функции программы, различные ее нефункциональные свойства
противоречат друг другу. Функциональность программы часто мешает
ее безопасности; модифицируемость — быстродействию; улучшение
практически любого свойства увеличивает стоимость разработки.

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

Компромисс в свойствах — компромисс в архитектуре. Именно выбор приоритетов
определяет наши решения в области архитектуры и дизайна создаваемой
программы. Эти решения, в свою очередь, в определяющей степени влияют на весь
наш продукт: на его коды, на пользовательскую документацию. Напомню при этом,
существуют свойства, которые проявляются не сразу, а только в ходе эксплуатации
(наша любимая безопасность, например), то есть, проблемы мы можем заметить
очень-очень поздно.

Понимаете, почему ошибка в архитектуре стоит дорого?

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

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

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

Классика классики: RUP

Пожалуй, самая известная методика 90-х, это Rational Unified Process.
Ее авторы постарались объединить все лучшее, что было известно к этому
моменту. Получилось несколько монструозно, но этот монстр сыграл
важную роль, и, более того, он до сих пор не потерял своей
актуальности.

RUP считается «тяжелым» процессом.

Поэтому, обсуждая классику, RUP я не мог не вспомнить.

RUP — шаблон (framework) для построения процессов разработки (см.,
например [Jacobson2002]). Это означает, что вы должны построить свой
процесс, используя средства, предоставляемые этим шаблоном. Было
показано, что RUP очень хорошо масштабируется и может быть использован
как для больших, так и для совсем крошечных проектов.

RUP считается «тяжелым» процессом. Действительно, с его помощью можно
создать программный продукт со всей документацией, которая была бы
разработана и в водопадном процессе. Поэтому RUP можно смело
рекомендовать для использования в самых больших проектах и для
разработки программ, качество которых необходимо будет доказывать
(например, ее надо будет сертифицировать).

С другой стороны, процесс может быть масштабирован и вниз. Так в 2002
году Филипп Крачтен, один из разработчиков RUP, описал
([Kruchten2002]) выполнение минимального проекта с использованием
этой методологии. Проект выполняется одним человеком за одну неделю!

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

/media/images2/RUP_process.png

Классическое изображение Rational Unified Process. Взято из
википедии

Как я уже сказал, авторы методики постарались внести в нее все лучшее,
что было известно к этому времени. Чтобы подробно рассказать об этом
процессе понадобилась бы целая книга. Я отмечу только главные его
отличительные черты.

Первое, RUP является итерационным и инкрементальным процессом.
Разработка ведется «итерациями», каждая из которых может занимать от
двух до шести недель. Итерации, конечно, направлены на снижение
рисков — явный реверанс в сторону спиральной модели.

Каждая итерация относится к одной из четырех фаз: запуск,
проектирование, реализация, внедрение и поддержка. Разделение на фазы
нестрогое, оно предназначено, скорее, для бо́льшего понимания прогресса
проекта. В этом можно убедиться, посмотрев на соотношение фаз и
действий в типичном проекте, которое демонстрируется на
рисунке-визитной карточке методики.

Второе, RUP ориентирован на решение проблем пользователя. Поэтому
одним из важнейших элементов планирования разработки являются
варианты использования. Каждый вариант использования — это описание
того, как пользователь достигает одной из своих целей, задействуя наш
программный продукт. Кстати, варианты использования в упрощенном виде
приняты и во многих (во всех?) современных гибких методиках под
названием «пользовательские истории».

Третье, проектирование продукта в RUP направлено на его архитектуру.
Мы уже обсудили, что качество программы зависит от архитектуры,
поэтому с использованием RUP мы можем создавать программное
обеспечение, к которому предъявляются жесткие требования качества
(напоминаю, включая надежность, безопасность…).

Четвертое, автоматизация разработки. RUP неразрывно связан с
программным обеспечением, поддерживающим процесс проектирования.
Думаю, именно с RUP надо связать развитие и популяризацию языка
визуального проектирования UML, ставшего классикой. Важным шагом
вперед стала и поддержка этими программными средствами модели
многомерного описания архитектуры программных систем «4+1»
([Kruchten1995]), тоже ставшей классикой.

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

Подведу итог этой части. Несмотря на многие проблемы (сложность,
дороговизна программного обеспечения), RUP сыграл свою важную роль в
истории разработки. Как вы заметили, одна из самых часто упоминающихся
фраз при его описании «ставший классикой». И этот процесс остается
важной методикой, которую можно рекомендовать для внедрения в очень
многих ситуациях.

Рождение «agile»

Как мы видим, уже к 90-м годам прошлого столетия инженеры и
руководители проектов располагали всем необходимым для быстрой и
гибкой разработки.

Итерационная и инкрементальная разработка, различные виды прототипов,
спиральная модель, объектное программирование, шаблоны проектирования,
начальные знания по шаблонам архитектуры, идеи линейки продуктов — все
это позволяло «поднимать» проекты очень разной сложности и
продолжительности.

/media/images2/Agile.png

Термин «agile» является зонтичным для целого набора методик. Этот
рисунок часто используется в интернете, найти его первоисточник
мне не удалось.

Тем не менее, мы знаем, что в конце 90-х и начале 0-х годов возникло
совершенно новое течение, я бы даже сказал, религия, в методиках
разработки — «agile».

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

Пузырь доткомов

В конце прошлого века началась новая эпоха в программировании. Зародилась она
в конце 80-х, начале 90-х годов, когда Тим Бернерс-Ли и Роберт Кайо сделали
пионерскую разработку: формат файла html и протокол обмена http. Результаты их
деятельности послужили основой для переворота в сети Интернет. Те, кто помнит более
раннюю Сеть, понимают, что я имею в виду.

Time-to-market!
Time-to-market!
Time-to-market!

Как всякие новые технологии, веб проходил определенные этапы развития:
зарождение, интерес энтузиастов, бум, охлаждение и выход на «плато».

Конец 90-х — это бум веб технологий. Процессы, происходившие в те
времена, можно было бы сравнить с временами «золотой лихорадки», о
которых писал Джек Лондон. В том числе, можно было бы найти и аналог
гонок на собачьих упряжках за владение потенциально золотоносными
участками. Есть ли там золото — сейчас не важно, сейчас главное —
застолбить этот участок, разрабатывать его будем потом, или это будут
делать другие.

Главный показатель успешности разработки в это время — «time-to-market».
Программистские компании очень быстро создавались и так же быстро
распадались. У них не было времени организовываться, решать, какие
технологии они будут использовать, у них не было времени закупать
средства разработки, у них не было времени тщательно продумывать
технические решения. Time-to-market! Time-to-market! Time-to-market!

Именно в это время и возник «agile». Да, многие технологии, попадающие
по зонтик «agile», зародились в больших компаниях. Это и Экстремальное
Программирование — XP (см., например, [Beck1999]), и Scrum
([Schwaber2001]) и другие. Но эти семена попали на плодородную почву
(да и кто сказал, что внутри больших компаний нет своих стартапов?).

Окончательно оформилась идеология «гибкости» уже в начале 2000-х
годов, с выходом «Agile Manifesto».

Agile Manifesto

Agile Manifesto был опубликован в 2001 году группой уважаемых
специалистов по разработке программного обеспечения. Этот манифест стоит того, чтобы быть здесь
процитированным:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

  • individuals and interactions over processes and tools
  • working software over comprehensive documentation
  • customer collaboration over contract negotiation
  • responding to change over following a plan

Последний параграф я хочу специально выделить, поскольку он является
основанием для многих споров:

That is, while there is value in the items on
the right, we value the items on the left more.

Этот параграф служит извинением для почти всех проблем «гибкости».
Пропоненты «гибких» методик, когда кто-нибудь начинает критиковать их
(методик) недостатки, сразу ссылаются на этот абзац: «мы же не
утверждаем, что полностью отказываемся от ценности планов, контрактов,
документации; мы просто говорим, что они имеют существенно меньшую
ценность, чем взаимодействие и рабочий код».

Правда, как при этом определить, где кончается гибкость и начинается
плановость? Сколько орехов — куча?

Поэтому давайте не будем здесь спорить о терминах. Я далее буду
говорить о «чистом» «гибком» подходе; возможно, я даже буду немного
утрировать, чтобы яснее показать разницу между классикой и
«гибкостью». Тем более что мне приходилось встречать фанатиков
«гибких» методик, которые настаивали именно на таком, утрированном, их
понимании.

Гибкость против плановости

Давайте пройдемся по всем четырем «мы больше ценим…» в Agile Manifesto
и посмотрим, что каждое из них обозначает на практике.

Итак, процессы и инструменты. В классической модели разработки мы
начинаем работу над проектом, когда у нас уже есть команда или хотя
бы ее ядро. Скорее всего, эта команда уже выполняла какие-то работы,
у нее есть определенные методики, формализованные и не очень; у этой
команды уже есть инструменты, которые все знают и которыми все
пользуются. Если такой команды нет, работа начинается с ее создания.

В гибкой модели подразумевается, что команда и методика разработки
«образуются» уже в процессе выполнения работ. Времени договариваться,
планировать, закупать инструменты нет. Отсюда требование:
высококвалифицированные специалисты, высокая мотивация, много общения.

Вообще, слово «образуется» («emerge») — вероятно, самое часто
используемое при описании гибких методик. «Образуется» команда,
архитектура, продукт…

Из всего широкого спектра возможностей в «гибких» методиках активно
используют только эволюционные прототипы.

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

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

Контракты. Классические методики подразумевают формализованные
договоренности с заказчиком. Эта формализация — логичное
следствие документированности общения. Прошла встреча, поговорили,
разошлись, мы присылаем заказчику резюме встречи. Он в ответ присылает
нам подтверждение, возможно, с некоторыми корректировками. Это, кроме
всего прочего, позволяет нам лучше понять потребности заказчика. Во
многих проектах такая переписка — вполне серьезные документы, на
основании которых нам платят (или не платят) деньги.

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

И, наконец, планирование. Главная мантра классической разработки:
«работает — не трогай». С самого начала мы продумываем архитектуру
продукта, его дизайн, пишем код так, чтобы при внесении изменений не
возникала необходимость трогать уже готовые части. Мы планируем.

Мантра гибкой методики: YAGNI — You Aint’t Gonna Need It. У нас нет
времени планировать; даже если бы оно было, мы не смогли бы
предсказать, что может понадобится заказчику в будущем. Поэтому мы
делаем сейчас только необходимый минимум, код, который будет работать
сегодня. Если завтра понадобится внести изменения — мы их сделаем.
Заказчик должен быть удовлетворен сегодня (вообще-то, еще вчера)!

И в заключение этой части, хочу подчеркнуть: абсолютной
«гибкости» не бывает ни в одном проекте! Как только мы начинаем
говорить об использовании любой методологии, будь то XP или, даже,
Scrum, мы уже отходим от чистой идеи.

Поддержание качества кода

Давайте обратим внимание, из всего широкого спектра возможностей в
«гибких» методиках активно используют только эволюционные прототипы,
программа «образуется».

Поддержание качества кода постоянно эволюционирующей программы — одна
из самых сложных задач. Не справимся с ней — получим все «прелести»
Code-and-Fix. Но я уже отмечал в этой статье, что эволюционное
программирование возникло уже давно. За время его существования были
найдены техники, позволяющие приспосабливать уже готовые части
программы к изменяющимся обстоятельствам. Таких техник существует
множество, назову некоторые из них: управляемая тестами разработка
(test driven development), непрерывная интеграция (continuous
integration), рефакторинг.

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

Написание тестов продолжается постоянно. Если в программе открывается
ошибка, которая не обнаруживается существующими тестами, пишется
еще один, направленный на обнаружение всех подобных ошибок.

Получается, что вся функциональность разрабатываемого продукта должна
быть покрыта тестами. Если в дальнейшем мы что-то в программе изменим
некорректно, это будет сразу обнаружено при следующем полном
тестировании. На практике, я ни разу не видел полного покрытия, но
бо́льшая часть, самая главная функциональность всегда покрывается.

Таким образом, управляемая тестами разработка позволяет изменять нашу
программу. Используя ее, мы можем не бояться, что улучшая одно, мы
сломаем что-то другое, и что эти некорректные изменения попадут в поставку
клиенту. Все проблемы будет быстро обнаруживаться и, по возможности,
исправляться.

Непрерывная интеграция позволяет нам обнаруживать некорректность
изменений как можно быстрее.

При непрерывной интеграции проводится частая, обычно, ежедневная
сборка программы. В эту ежедневную сборку попадают все более или менее
готовые изменения; собранная программа полностью тестируется. Полное
тестирование — процесс долгий, но автоматизированный, и поэтому
проводится он чаще всего ночью, без участия людей. Таким образом,
если кто-то, что-то испортил, это будет ясно уже на следующее утро.

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

В ходе рефакторинга мы изменяем архитектуру и дизайн программы, не
изменяя при этом ее функциональности. Проводить этот процесс бывает
необходимо, чтобы приспособить разрабатываемую программу к
изменившимся условиям: требованиям заказчика, нашего понимания путей
ее развития, появившимся новым технологиям.

Меняя структуру программы, мы меняем и ее свойства. Как мы помним,
архитектура и дизайн определяют нефункциональные свойства
программы, в том числе, модифицируемость, надежность, безопасность и
многие другие. Если нас не удовлетворяет любая из этих характеристик
в текущей версии, мы можем провести ее рефакторинг; на практике,
разработчики больше всего заботятся о модифицируемости.

Таким образом, рефакторинг позволяет нам избежать в «гибких»
методологиях проблем Code-and-Fix. Поэтому он рассматривается, как
одна из ключевых практик таких методик, и способы его проведения
хорошо проработаны (см., например, [Fowler1999]).

В свою очередь, рефакторинг поддерживается автоматизированным
тестированием и (часто) непрерывной интеграцией. Делая регулярное
тестирование, мы в любой момент можем быть уверенными, что наши
изменения архитектуры и дизайна не изменили функциональности
программы.

Хочу обратить ваше внимание на интересное противоречие. С одной
стороны, использую «гибкие» методы, мы декларируем возможность не
следовать каким-либо процессам. С другой стороны, если мы хотим в
результате получить качественный продукт, мы должны выполнять вполне
определенные, очень важные действия. Поэтому, например, один из самых
известных методов «гибкой» разработки, eXtreme Programming (XP),
считается процессом, который достаточно сложен для исполнения в полном
объеме (см., например, [McBreen2002]).

Разрешается это противоречие при одном, очень важном условии:
«гибкая» методика используется очень квалифицированной группой,
которая понимает, что она делает. Только в этом случае такая группа
сможет произвести продукт с приемлемым качеством.

Проблемы роста

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

Однако надо понимать, что «гибкость» хороша не
всегда. Существует множество публикаций, в которых ограничения этих
методологий обсуждаются очень подробно. Например, я могу
порекомендовать статью «Assumptions Underlying Agile Software
Development Processes» ([Turk2005]); это довольно объемная работа (38
страниц), и тема ограничений раскрыта достаточно полно.

Я же только приведу некоторые примеры.

Давайте представим себе достаточно типичную ситуацию. Мы в наше
быстроменяющееся время начали создавать новый программный продукт; мы
создавали команду; мы искали концепцию продукта; мы искали клиентов,
готовых купить нашу программу. Вполне естественно, что мы начали с
«гибкой» методики разработки.

Мы пришли к успеху. Гонки на собачьих упряжках выиграны, мы вышли на
рынок, наш продукт пользуется спросом, наша компания развивается. И
мы начинаем понимать, что наша «гибкая» методика ограничивает
наш рост.

Квалификация разработчиков

Одно из ограничений, с которым мы сталкиваемся, это отсутствие
необходимого количества квалифицированных специалистов.

Сначала давайте договоримся, как мы будем характеризовать
квалификацию. Алистер Коберн — один из ведущих мировых специалистов по
разработке ПО, один из создателей «agile manifesto», создатель
«гибкого» метода Crystal — различает три уровня
квалификации специалиста (по аналогии с восточной оценкой
компетентности Сю Ха Ри).

Первый уровень — начальный. При этом уровне квалификации специалист
понимает методику, он знает и соблюдает ее правила. Специалист с
квалификацией первого уровня в точности следует рецептам,
предписаниям, исполняет инструкции.

Второй уровень — продвинутый. Специалист с этим уровнем квалификации
понимает ограничения методики, он знает, что иногда полезно правила
нарушать.

И, наконец, третий уровень — эксперт. Специалист этого уровня
квалификации вообще может не задумываться, какую методику он
использует; в каждый момент времени он делает то, что наилучшим
образом приводит к успеху.

Выше квалификация — ниже требуемый уровень регулирования. Очевидно,
что группа специалистов с компетентностью третьего уровня выполнит
работу лучше, если она не будет ограничена какими-либо «формальными
процессами». Такая группа либо повторит формализованный процесс — если
он является в данном случае оптимальным, — либо найдет свой, более
другой способ. Формальности такой группе только мешают работать.

Вернемся к нашей воображаемой компании. Предположим, мы начали ее, как группа
высококлассных специалистов; конечно, «гибкие» методики очень помогли в нашем
становлении. Мы создали классный продукт и теперь его развиваем. Нам надо
расширяться, нанимать новых программистов. Найти таких же классных
специалистов, как мы сами (!) очень сложно. Но нужно ли?

Классному программисту интересна далеко не всякая работа. Есть
множество вещей в программировании, которые являются рутиной, которые
отвлекают от Творчества. Конечно, именно для выполнения таких задач мы
в первую очередь и ищем новых сотрудников; и мы не хотим им платить
слишком много (зачем?). Конечно, мы приглашаем специалиста попроще.

Возникает задача адаптации новых сотрудников. Адаптировать
высококлассного специалиста было бы не слишком сложно, он и сам легко
бы во всем разобрался. Более того, новый высококлассный специалист
внес бы в нашу группу новые идеи. Но мы же нанимаем специалиста
попроще — с ним приходится повозиться. Наняв одного, мы с легкостью
объясняем ему, как у нас принято работать; наняв второго, мы тоже ему
легко все объясняем, но это уже начинает быть скучным делом. Чтобы не
повторять одно и то же по нескольку раз, мы пишем инструкцию (или,
даже, инструкции).

Так мы начинаем формализовать и документировать наши процессы.

Время и память

Документирование проекта — вещь крайне скучная. Найти решение сложной
проблемы, написать хорошую программу — это «fun», описать, как это все
сделано — почти наказание. Кроме того, документирование проекта —
дополнительная работа, которая не вносит ни капли в главное — в коды
продукта. Отказываясь от создания проектной документации, мы экономим
наши силы раза в два, как минимум. Мы сокращаем стоимость нашего
продукта, и мы можем выпустить его быстрее!

Но у всего есть своя цена.

У программистов есть мудрость: «вы начинаете комментировать свои
программы после того, как один раз попробовали разобраться в своей же
работе год спустя».

Мы начинаем документировать наши проекты после того как:

  • мы нашли классное решение проблемы;
  • мы реализовали это решение;
  • мы обнаружили, что «это» ломает нашу программу;
  • мы вспомнили, что уже делали «это» год назад, с тем же результатом.

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

Я поддерживаю несколько другую точку зрения. Никто не спорит — код
должен быть понятен, должно быть понятно, что он делает.
Документация отвечает на вопросы: зачем он это делает, и
почему именно так, а не по-другому. Проблема проектной
документации не в том, что приходится ее писать, а в том, что ее пишут
плохо.

И мы все равно, рано или поздно, приходим к документированию. Сначала
мы делаем подробные комментарии в коде, комментарии в системе
управления версиями; мы записываем задачи в систему управления
ошибками (bug tracker). Потом и этого становится мало, и мы начинаем
записывать требования клиента, описывать архитектурные решения, дизайн
программы.

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

Магические «7±2»

В «гибких» подходах приняты «бездокументальное» программирование и
коллективное владение кодом. Про бездокументальное программирование мы
уже поговорили — оно позволяет не делать «лишней» работы. Коллективное
владение кодом означает, что каждый член группы имеет право (и должен)
вносить изменения в любую часть программы.

Коллективное владение кодом — очень разумный подход. Действительно,
если мне надо добавить функцию, исправить какую-либо ошибку, то я не
обязан это ни с кем это согласовывать, мне не надо сообщать другому
программисту (или, что еще хуже, его руководителю). Я не должен ждать,
пока кто-то это сделает; я просто делаю, что мне (и всей группе в
целом) нужно. Никакой бюрократии!

Но программа растет, а наш мозг ограничен. Наверно, все вы слышали о
классических «7±2». Эти магические цифры означают количество единиц
информации, с которыми может работать наш мозг одновременно.

«Единица» информации в данном случае — это вещь, определяемая весьма
приблизительно. Сильно упрощая, для целей нашей статьи можно
считать, что это одна из абстракций, которыми мы оперируем: элемент
архитектуры, дизайна, подпрограмма, функция, переменная… Чем больше их
становится, тем сложнее уместить их в нашем сознании.

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

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

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

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

Территориальная разъединенность

Разработка программы в группе — это обмен информацией. Мы должны
взаимодействовать с заказчиком, мы должны взаимодействовать между
собой.

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

Но мы живем в большом мире. Часто производить программный продукт
выгоднее не там, где находится заказчик (подумайте, пресловутый
«индийский код» появился не просто так). Даже в России мы можем
наблюдать это: большинство заказчиков программного обеспечения
находятся в Москве, но цена программиста — причем не самого опытного —
здесь очень высока.

Разделяя наших сотрудников географически, мы можем получить более
эффективную бизнес модель. Действительно, мы можем оставить
(например) в Москве только специалистов, работающих с заказчиком,
выясняющих его требования, производящих высокоуровневое
проектирование. Модульное проектирование, реализацию, тестирование
можно осуществлять там, где это удобнее.

Конечно, время от времени, разработчикам надо будет встречаться. Но
все же, самый большой объем обмена информацией в этом случае будет
происходить в письменном виде.

Таким образом, географическое разделение труда является еще одной
причиной делать проектную документацию.

Разрешение конфликтов

«Гибкая» разработка подразумевает наличие мотивированного,
сотрудничающего заказчика. Причем представлен этот заказчик (как
минимум, в идеале) одним человеком, который разбирается в проблеме и
имеет право принимать решения по поводу разрабатываемого продукта.

«Wow!» — сказали бы американцы.

В реальности, наш заказчик далеко не один человек. Требования к
создаваемой программе являются результатом компромиссов между очень
различными группами людей внутри компании-заказчика: это и конечные
пользователи, и технические специалисты, и финансисты, и безопасники…
Если вы сдаете даже небольшую программу в такой компании, не
удивляйтесь, когда на приемке присутствует десяток человек. Часто,
даже то, что за разработкой обратились к нам, а не к нашему конкуренту
— результат компромисса, сложных игр.

Разрешение конфликтов в технической области — задача не самая легкая.
Методикам решения возникающих при этом проблем уделяется очень много
внимания, им посвящены даже не статьи, а целые книги. Я приведу только
один пример.

ATAM, Architecture Tradeoff Analysis Method ([Bass2012]) был создан
для использования в больших проектах. Согласно этой методике все
заинтересованные стороны, как со стороны заказчика, так и со стороны
разработчика, собираются на конференцию (даже не на совещание). Они
обсуждают возможные решения, их достоинства и недостатки; в ходе
обсуждение дается возможность высказаться всем заинтересованным
сторонам, и, возможно, консультантам. В конце конференции производится
голосование, в ходе которого выбирается техническое решение, и именно
оно становится базой для создания нового программного обеспечения.

Понятно, ATAM — методика с другой от «гибкости» стороны. Но даже в
относительно небольших проектах мы можем столкнуться с проблемами,
вызванными конфликтами внутри компании-заказчика. Поэтому четко
прописанные технические решения и процедуры их пересмотра бывают
крайне необходимы.

Требования к качеству

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

С другой стороны, главная задача «гибкой» разработки — удовлетворить
клиента сейчас. Причем, представить продукт надо быстро, очень
быстро, совсем быстро, быстрее, чем это сделают другие
(time-to-market). Тогда, если клиент не видит какое-то свойство
сейчас, надо ли тратить время на его обеспечение?

Да, конечно, исправление ошибок потом — дело дорогое. Но тогда клиент
уже купит нашу программу, мы «подсадим» его на наши разработки, он
оплатит новые, улучшенные версии.

Это похоже на ипотеку. Мы можем долго копить на свой дом, а можем
сейчас взять в долг и наслаждаться собственностью. За возможность
получить что-то быстро сейчас, мы вынуждены переплачивать потом.
Ситуация настолько похожа, что ее часто называют термином «технический
долг».

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

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

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

Оставаясь полностью в рамках гибкого подхода, это сделать трудно.

Действительно, в рамках «гибкого» подхода мы вынуждены часто делать
рефакторинг. Напомню, что рефакторинг — это изменение архитектуры
программы без изменения ее функциональности. Мы осуществляем его, чтобы
сохранить «высокое качество» кода.

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

Поэтому после рефакторинга мы должны проверять полученный результат.
Проверить, что функциональность не изменилась, позволяют
автоматизированные тесты; они проходят почти без нашего участия,
поэтому их можно проводить каждую ночь (правда, для больших продуктов
полное тестирование может занять несколько суток, но все равно, оно
проходит почти без нашего участия). А вот чтобы проверить, например,
безопасность, надо приложить немало усилий.

Есть, конечно, и возможность упростить нашу задачу. Нам не надо
проводить проверку безопасности после каждого рефакторинга, мы
должны это сделать до поставки программного обеспечения клиенту. Но
при «гибкой» разработке мы делаем частые поставки!

Поэтому, когда мы используем чисто «гибкие» методики, у нас есть два
варианта. Во-первых, мы можем таки делать анализ перед каждой
поставкой; тогда стоимость разработки будет очень велика. Во-вторых,
мы можем допустить некоторое снижение безопасности в промежуточных
поставках; тогда мы можем делать анализ не так часто; мы понижаем цену
разработки, но повышаем риски заказчика.

Более интересным является вариант, когда мы отходим от «гибкой»
методологии. Действуя по этой схеме, мы планируем архитектуру
системы таким образом, чтобы она была разделена на две части.

Первая часть — ядро системы. Мы тщательно его проектируем,
анализируем, кодируем, тестируем и фиксируем. В дальнейшем, для
внесения в ядро изменений требуются очень серьезные обоснования.
Поскольку мы хотим получить безопасность (среди всех прочих качеств)
как можно дешевле, мы делаем так, чтобы вся защита полагалась на это
ядро. Тогда необходимость в дорогостоящем анализе возникает редко, и
поэтому мы можем проводить его более тщательно.

Вторая часть нашей системы — гибкая. Мы проектируем систему так, чтобы
ошибки в этой части не приводили к серьезным уязвимостям (замечу, это
уже само по себе не самая простая задача). Поэтому гибкую часть можно
менять очень быстро, приспосабливать к изменяющимся запросам клиентов,
не боясь испортить качества системы в целом. Мы должны только
предпринять какие-то меры, чтобы изменения в этой части не портили
ядро (например, в операционных системах ядро работает в особом режиме
процессора).

Таким образом, мы видим, что по мере усиления требований к качеству
продукта, становится более экономически выгодным отход от чисто
«гибких» методик и переход к планированию архитектуру, переход от
развития одной программы к созданию линейки продуктов.

Заключение

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

Сниженные требования к качеству можно встретить достаточно часто. Так
бывает, например, если мы работаем в сегменте рынка, где качеству
вообще не уделяют большого внимания (посмотрите, например, на
современные социальные сети). Другим примером может быть ситуация,
когда для клиента риски связанные с дефектным программным
продуктом покрываются выгодами от раннего выхода на рынок.

По мере роста размера программы и/или ужесточения требований появляется
необходимость отходить от чисто «гибкой» разработки. Мы начинаем с добавления
небольших элементов плановости: немного формализуем процесс, немного
документируем продукт, немного планируем архитектуру и замораживаем код.

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

Возможно, в какой-то момент мы должны будем перейти к классике.
Причем, такой переход будет означать не просто сказанное «все, мы уже
не используем agile», это будет означать новые методы разработки,
новые правила, новые инструменты, возможно, новые сотрудники.

Все то же самое можно сказать и более формально. Действительно,
давайте рассмотрим «гибкие» методики с точки зрения спиральной модели.
Очевидно, «гибкость» нужна, если главный риск проекта — опоздание с
выходом продукта на рынок. Как только этот риск становится меньше, или
другие риски становятся более существенными (например, недовольство
клиентов низкой надежностью), мы должны задействовать другие методы
решения наших задач.

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

Постскриптум

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

Допуская гибкость, вы получаете целый ряд преимуществ:

  • увеличение скорости и снижение стоимости работы за счет отсутствия
    необходимости планирования;
  • получение более качественного результата за счет отсутствия
    искусственных ограничений, наложенных на высококвалифицированных
    специалистов.

Поэтому разумная гибкость — дополнительное конкурентное преимущество.
Даже SEI, организация, проповедующая очень плановый подход (это такие
«тяжелые» методики, как PSP, TSP и CMMI), заявляет, что не видит ничего
плохого в гибкости ([Glazer2008]).

Гибкость хороша везде, где работают высококвалифицированные
специалисты. Поэтому большу́ю степень гибкости можно, например,
допускать на стадиях выяснения требований и высокоуровневого
проектирования — стадиях, на которых производится очень активное
прототипирование.

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

На своих курсах для безопасников я критикую именно отсутствие
гибкости. И я мог бы написать еще одну такую статью с описанием, как
вредит излишняя косность.

Здесь нет противоречия. Каким-то группам не хватает гибкости, каким-то
— плановости. Все зависит от решаемых в данный момент задач.

И в заключение, я рекомендую почитать книгу Боэма «Balancing Agility
and Discipline — A Guide for the Perplexed» ([Boehm2004]), (да-да,
это тот самый Боэм, который предложил спиральную модель). В ней Боэм
очень подробно обсуждает риски как плановых, так и гибких методик, а
также предлагает подход по уменьшению этих рисков. Если вы дочитали до
конца этой статьи, то, почти уверен, книга будет вам тоже интересна.

Спасибо за внимание, и удачи вам в ваших разработках!

Литература

[Barroca2000] Leonor Barroca, Jon Hall, Patrick Hall «Software
architectures — advances and applications»,
Springer, 2000
[Bass2012] (1, 2, 3) Len Bass, Paul Clements, Rick Kazman «Software
Architecture in Practice», Addison-Wesley
Professional, SEI Series in Software Engineering, 3
edition, 2012
[Beck1999] Kent Beck «Extreme programming explained: embrace
change», Addison-Wesley Professional, 1999
[Boehm1986] Barry W. Boehm, «A spiral model of software development and
enhancement», ACM SIGSOFT Software Engineering Notes, Volume 11
Issue 4, 1986
[Boehm1988] (1, 2, 3, 4) Barry W. Boehm, «A spiral model of software development and
enhancement», Computer, IEEE Computer Society Press Los Alamitos,
Vol. 21, Issue 5, 1988
[Boehm2000] Barry W. Boehm, «A spiral model of software
development: Experience, Principles, and Refinements», Special Report
CMU/SEI-2000-SR-008, 2000
[Boehm2004] Barry W. Boehm and Richard Turner «Balancing Agility and
Discipline — A Guide for the Perplexed»,
Addison-Wesley, 2004
[Carr1997] Mahil Carr, June Verner, «Prototyping and Software
Development Approaches», Techreport, City University
of Hong Kong, Department of Information Systems, 1997
[Cialdini] Роберт Чалдини, «Психология влияния», Питер,
Harper Collins College Publishers, 3-е издание, 2000
[Eden2003] Amnon H. Eden, and Rick Kazman «Architecture, Design,
Implementation.» ICSE, page 149-159. IEEE Computer
Society, 2003
[Floyd1984] (1, 2) Christiane Floyd, «A systematic look at prototyping»,
in book Approaches to prototyping,
Proceedings of the Working Conference on Prototyping,
Springer, 1984
[Fowler1999] Martin Fowler, Kent Beck, John Brant, William Opdyke,
Don Roberts «Refactoring: Improving the Design of
Existing Code», Addison-Wesley Professional, 1999
[Gamma1995] Erich Gamma, Richard Helm, Ralph Johnson, and John
Vlissides «Design Patterns: Elements of Reusable
Object-Oriented Software» Addison-Wesley Longman
Publishing Co., Inc., Boston, MA, USA, 1995
[Gilb1988] Tom Gilb «Principles Of Software Engineering
Management», Addison-Wesley Professional, 1988
[Glazer2008] Hillel Glazer, Jeff Dalton, David Anderson,
Mike Konrad, Sandy Shrum «CMMI® or Agile:
Why Not Embrace Both!» Software Engineering Institute,
Carnegie Mellon University, 2008.
[Jacobson2002] Айвар Якобсон, Грэди Буч, Джеймс Рамбо
«Унифицированный процесс разработки программного обеспечения»,
Питер, Addison-Wesley, 2002
[Kruchten1995] Philippe Kruchten, «Architectural Blueprints — The
«4+1» View Model of Software Architecture», IEEE
Software, Volume 12, pages 42—50, 1995
[Kruchten2002] Philippe Kruchten «A Software Development Process
for a Team of One», The Rational Edge, 2002
[McBreen2002] Pete McBreen, «Questioning Extreme Programming»,
Pearson Education; 1st edition, 2002
[McConnell1996] (1, 2) Steve McConnell «Rapid Development: Taming Wild
Software Schedules», Microsoft Press, 1996
[McCracken1982] Daniel D. McCracken, Michael Jackson «Life cycle
concept considered harmful», SIGSOFT Softw. Eng.
Notes, Vol. 7, Issue 2, 1982
[Pohl2010] Klaus Pohl «Requirements Engineering: Fundamentals,
Principles, and Techniques», Springer; 2010 edition,
2010
[Ralph2013] Paul Ralph, «The Illusion of Requirements in Software
Development» Requirements Engineering, Volume 18, Issue 3,
September 2013
[Royce1970] Winston W. Royce, «Managing the development of large software systems:
concepts and techniques», Proc. IEEE WESTCON, IEEE
Press, 1970
[Taylor2009] (1, 2) R. N. Taylor, N. Medvidovic, and E. M. Dashofy.
«Software Architecture: Foundations, Theory,
and Practice». Wiley Publishing, 2009.
[Schwaber2001] Ken Schwaber, Mike Beedle «Agile Software
Development with Scrum» Prentice Hall, 2001
[Swartout1982] William Swartout, Robert Balzer, «On the inevitable intertwining
of specification and implementation», Commun. ACM,
Volume 25, Issue 7, 1982
[Turk2005] Daniel Turk, Robert France, Bernhard Rumpe
«Assumptions Underlying Agile Software Development
Processes» Journal of Database Management, v. 16, pp.
62-87, 2005

— адрес электронной почты не проверяется и никому, кроме меня, не показывается
— для форматирования комментариев можно использовать markdown
— для отслеживания комментариев на этой странице можно подписаться на atom feed

Источник

  • Как методологии разработки программного обеспечения влияют на запуск IT-проекта?

  • Что такое программное обеспечение?

  • Этапы разработки и жизненного цикла ПО

  • Модели разработки ПО

  • «Водопад» — каскадная модель (Waterfall)

  • V-образная модель — через тестирование (V-model)

  • Инкрементная модель (Incremental model)

  • Итеративная или итерационная модель (Iterative Model)

  • Спиральная модель (Spiral Model)

  • Развертывание DevOps как подход в разработке ПО

  • Agile: модель или методология?

  • Особенности Agile

  • Популярные гибкие методологии разработки программного обеспечения

  • Самое важное

  • Связаться со специалистом LeanTech

Основа для успешного запуска IT-проекта складывается из правильной интерпретации бизнес-целей, взаимодействия с клиентами (учета их потребностей и нужд) и расстановке приоритетов. Все эти критерии — следствие в выборе подхода разработки ПО.

В этой статье рассмотрим методологии разработки программного обеспечения и под какие задачи бизнеса они подходят.

Начнем с того, что именно представляет собой ПО.

Что такое программное обеспечение?

Программное обеспечение — то, что позволяет нам (обычным пользователям) выполнять любые действия с компьютером. Взаимодействие любого пользователя с компьютером без ПО невозможно.

Например, без интернет-браузера (Google Chrome, Yandex и т.д.) никто не смог бы пользоваться интернетом. А без операционной системы (Windows, Android, macOS и др.) невозможна работа интернет-браузера.

Здесь два примера программного обеспечения: интернет-браузер и операционная система. Интернет-браузер также — программа, а ОС при этом — нет. Таким образом, все программы — это ПО, но не все ПО — программы.

Когда есть цель — разработать проект программного обеспечения, как это сделать? Как происходит процесс?

Этапы разработки и жизненного цикла ПО

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

Стандартный цикл

: подготовительный этап, проектирование, разработка (создание) и поддержка.

Этапы и методологии разработки программного обеспечения><meta itemprop=

Этапы разработки проекта программного обеспечения

Теперь рассмотрим эти процессы на примере

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

Подготовка.

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

Проектирование.

Руководители выбрали компанию-подрядчика для создания программного обеспечения и обсудили архитектуру и дизайн будущего IT-продукта с ее специалистами.

Создание.

Руководители сети магазинов заключили договор с разработчиками. Специалисты запустили кодирование, начали отрисовывать дизайн и составлять необходимую документацию.

Поддержка.

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

Так выглядит стандартный процесс разработки проекта программного обеспечения.

Кроме того, есть еще два понятия: модель и методология разработки ПО. Что это такое и в чем разница?

Модель разработки ПО — про то, какие стадии или этапы жизненного цикла оно проходит и что именно происходит на каждой из них.

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

Далее — расскажем подробнее о популярных моделях разработки ПО, их плюсах и минусах.

Модели разработки ПО

Существует достаточно широкий ряд моделей разработки ПО:

  • модель кодирования и устранения ошибок (Code and fix),
  • каскадная модель или «водопад» (Waterfall),
  • V-образная модель — разработка через тестирование (V-model),
  • инкрементная модель (Incremental Model),
  • итеративная или итерационная модель (Iterative Model),
  • спиральная модель (Spiral Model),
  • прототипная модель (Prototype Model) и др..

Из этого ряда наиболее популярные:
✔️ каскадная,
✔️ V-образная,
✔️ инкрементная,
✔️ итерационная
✔️ и спиральная.

На них остановимся, рассмотрим более подробно.

Популярные модели и методологии разработки программного обеспечения

Виды популярных моделей разработки ПО по данным ScienceSoft

«Водопад» — каскадная модель (Waterfall)

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

Преимущества

✔️

Простой контроль.

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

✔️

Определение стоимости на начальном этапе.

На этапе согласования договора планируются все шаги разработки, поэтому написание ПО от начала до конца происходит непрерывно.

✔️

Нет необходимости в тестировщиках высокого уровня.

Подробная техническая документация позволяет успешно проводить тестирование специалистам без серьезной технической подготовки. Это помогает заказчику сэкономить общую стоимость создания проекта.

Недостатки

❌

Тестирование на последних этапах.

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

❌

Возможность посмотреть готовый IT-продукт заказчику только в конце разработки.

Это нередко влечет несоответствие ожиданиям и, соответственно, неудовлетворенность заказчика.

❌

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

Чем больше масштаб проекта и объем необходимой документации, тем больше корректировок необходимо вносить, тем дольше происходит их согласование.

Каскадная модель хорошо подходит для разработки ПО в сфере медицины или космоса, т.к. в них уже есть обширная база документов (СНиПы и спецификации), на их основе легче и быстрее написать требования к новому проекту.

V-образная модель — через тестирование (V-model)

Данная модель — усовершенствованная версия каскадной. Здесь заказчик с командой разработчиков составляют ряд требований к системе одновременно, описывают, как будет происходить тестирование на каждом этапе. Появилась данная модель разработки в начале 1980-х гг.

Преимущество

✔️ Сведение к

минимуму количества ошибок

в архитектуре ПО.

Недостаток

❌

Высокая стоимость исправления допущенной ошибки

при разработке архитектуры (как и в каскадной модели).

V-образная модель подходит разработке тех продуктов, для которых важна надежность — например, системы видеонаблюдения в сфере медицины и здравоохранения.

Инкрементная модель (Incremental model)

Основная суть этой модели — разработка по частям. Появилась она в 1930-е годы. Разберем ее принцип на практическом примере — разработке мессенджера. ❕

Некто (заказчик) принял решение, что желает создать и запустить собственный мессенджер, и написал техническое задание. Команда разработчиков предложили реализацию базовых функций: страницу профиля пользователя и чат непосредственно для общения, а потом — протестировать, чтобы понять «зайдет или нет».

Разработчики демонстрируют продукт заказчику и делают релиз (выпуск на рынок). В случае удовлетворенности заказчика и пришедших пользователей дальнейшая работа продолжается по частям.

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

Преимущества

✔️

Экономный старт.

В самом начале заказчик платит только за разработку базовых функций, и сразу имеет возможность получить продукт и протестировать его запуск на рынке.

✔️

Высокая скорость в получении обратной связи от аудитории и корректировании технического задания.

Таким образом, риск разработки ненужного продукта сводится к минимуму.

✔️

Минимальная стоимость ошибки.

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

Недостаток

❌ Возможные

расхождения в разработке функциональности

разными специалистами (различия в интерфейсе). Здесь важно в самом начале обсудить и обозначить, каким именно он будет, для достижения единого понимания и представления.

Инкрементная модель подходит для IT-проектов, в которых есть возможность в самом начале прописать точное техническое задание и цель — быстрый выход на рынок.

Итеративная или итерационная модель (Iterative Model)

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

Вернемся к примеру разработки мессенджера. Процесс его создания по итеративной модели выглядит следующим образом. ⬇️

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

Приложение запустили на рынок — в магазин приложений для тестирования. Пользователи (целевая аудитория) начали скачивать и использовать, т.е. продукт начал пользоваться популярностью, поэтому заказчик принял решение о его доработке.

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

Преимущества

✔️

Быстрый запуск MVP

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

✔️

Непрерывное тестирование

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

Недостатки

❌

Использование на старте баз данных

усложняют возможность дальнейшего масштабирования.

❌

Использование серверов

(вместо баз данных) не позволяют выдерживать высокую нагрузку.

Эти два момента способствуют риску переписывания большей части приложения.

❌

Нет фиксированного бюджета и сроков

. У заказчика нет четкого понимания, какая конечная цель и когда разработка будет завершена.

Для разработки масштабных проектов с неопределенными требованиями или для проектов с инновационным подходом (когда у заказчика нет уверенности в конечном результате) хорошо подходит итеративная модель.

Спиральная модель (Spiral Model)

При выборе данной модели команда разработчиков проводит тщательный анализ рисков проектов, а создание программного обеспечения производится пошагово. Каждый последующий этап основывается на предыдущем. В конце каждого «витка» (цикла шагов) принимается решение о том, целесообразно ли продолжать работу над IT-проектом. Данная модель появилась в конце 1980-х гг.

Схема разработки по данной модели представлена ниже.

Модели и методологии разработки программного обеспечения. Спиральная модель.

На примере создания системы для автоматизации бизнес-процессов внутри компании рассмотрим принцип функционирования данной модели. Подробнее о том, что такое ERP-система, уже рассказали в статье здесь.

Заказчик принял решение о создании системы для управления своим бизнесом, но не понимал, работу каких именно отделов желает оптимизировать, оформил заказ у компании-подрядчика. Команда специалистов начала работать по каскадной модели, разработали базовое ПО для оптимизации процессов одного из отделов (например, отдел кадров).

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

Команда разработчиков создала систему, оптимизирующую бизнес-процессы остальных отделов, на базе предыдущих. Заказчик протестировал, провел анализ. Разработка завершена.

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

Преимущество

✔️ Тщательная

проработка рисков

.

Недостатки

❌

Риск остановиться

на первом этапе разработки.

❌

Большие временные

затраты.

❌

Высокая стоимость

.

Такая модель подходит для проектов с высокими рисками (например, исследовательская сфера), в случаях, когда заказчик затрудняется определить точный ряд требований или когда ожидается внесение значительных корректировок в ходе разработки.

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

Развертывание DevOps как подход в разработке ПО

DevOps означает разработку ПО (Dev — development) и IT-операции (Ops — operations). Основа этого подхода в объединении двух сторон создания IT-продукта — разработки ПО и улучшения процессов в единое целое.

Здесь команда специалистов работает над проектом пошагово, при этом фокусируется на автоматизации процессов, прозрачности процессов и оперативной обратной связи.

Такой подход позволяет оптимизировать ✔️ скорость разработки, сохраняя ✔️ высокое качество, ✔️ согласованность и ✔️ надежность.

На данный момент DevOps активно применяется в сферах финтеха и телекоммуникаций.

Подробнее об услуге DevOps от нашей команды LeanTech рассказано здесь.

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

Также Вы можете написать нашему специалисту напрямую через наиболее удобную соцсеть.

На основе уже упомянутой итеративной модели появилось понятие Agile.

Agile: модель или методология?

Ввиду того, что в каждой модели после появления обнаружены определенные недостатки (по каждой модели мы их рассмотрели выше), поиски оптимальных решений продолжались. Принципы работы по каждой модели комбинировали, корректировали. Так и появился термин Agile.

Agile не относится ни к моделям, ни к методологиям разработки программного обеспечения. Это скорее подход к разработке.

Agile в переводе — гибкий. По истории своего появления данный подход собрал разные методологии, практики и подходы, которые способствуют

более эффективному созданию программного обеспечения.

К Agile относятся:
✔️ методология «чистой комнаты»,
✔️ методология разработки Microsoft Solutions Framework — MSF,
✔️ экстремальное программирование,
✔️ Scrum — фреймворк для управления проектами,
✔️ разработка через тестирование,
✔️ бережливая разработка ПО,
✔️ FDD — разработка, управляемая функциональностью,
✔️ метод управления разработкой Kanban,
✔️ метод разработки динамических систем — DSDM,
✔️ итеративно-инкрементальный метод разработки.

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

Место Agile среди моделей и методологий разработки программного обеспечения

Agile среди моделей и гибких методологий разработки программного обеспечения

Ценности Agile породили более 50 методологий, часть из них мы обозначили выше. Из большого списка Scrum является самой популярной. Рассмотрим пару наиболее популярных методологий.

Популярные гибкие методологии разработки программного обеспечения

Scrum

Здесь при разработке определяется Scrum-мастер, обеспечивающий непрерывную работу всей команды разработчиков, создавая необходимые условия (мотивация, проведение встреч и т.д.). Также выделяется роль руководителя разработки — он следит за продуктом, выступает главным звеном между заказчиком и командой.

Scrum подходит для проектов, включающих до 10 человек.

Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы четко прописаны. Помимо Scrum, часто используют Kanban.

Kanban

В переводе с японского — карточка. Отличие в визуализации цикла разработки. Специалисты ориентируются на выполнение задач, которые нужно сдавать в индивидуальном порядке. Цель каждого специалиста в команде — минимизировать количество задач в списке «выполнить» (еще не начатых).

Такой подход позволяет понять, где именно возникла проблема, и просто

обеспечивает наглядность

всей работы.

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

Теперь поясним, как добиться бизнесу (заказчику разработки) наиболее эффективного контроля процесса создания программного обеспечения, т.е. желаемого IT-продукта.

Самое важное ❗️❗️❗️

Методов разработки ПО много, выбор зависит от особенностей (целей, задач и т.д.) конкретного заказчика или бизнеса.

  • Каскадная модель (водопад) подходит в тех случаях, где есть четкие требования и техническое задание, а также уверенность, что они не будут меняться в процессе создания продукта.
  • Для инновационных проектов, где уровень непредсказуемости высок, более удачным станет выбор одного из гибких методов, т.к. они позволяют оперативно реагировать на необходимые изменения и производить их.
  • Если компании важно максимальное удобство в процессах создания желаемого IT-продукта и в контроле организации, то есть удобная услуга у компаний-подрядчиков — разработка под ключ. Она позволяет максимально качественно провести всю работу от начала и до конца и получить решение, максимальным образом отвечающее начальным требованиям, целям, задачам и пожеланиям заказчика.

Если вам нужна помощь в разработке программного обеспечения или разработка под ключ, наши специалисты готовы помочь. Для этого перейдите по кнопке «Оставьте заявку» сразу под текстом и оставьте контактную информацию, чтобы наши менеджеры могли с вами связаться в ближайшее время.

Наша команда специалистов с 2014 года помогает своим заказчикам реализовывать свои идеи и задумки в сфере IT.

Делаем так, чтобы заказчику было максимально комфортно контролировать весь процесс, и все этапы были прозрачными.

Наши кейсы можно посмотреть здесь.

Источник

https://gbcdn.mrgcdn.ru/uploads/post/1168/og_image/a7c9405c70331cef17f9a8e903ff8c62.jpg

За прекрасную картинку спасибо Toggl.com.

Подготовлено по материалам вебинара «Модели и методологии разработки ПО» Анастасии Кайгородовой, преподавателя факультета тестирования ПО.

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

Этапы жизненного цикла ПО

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

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.

Подготовка. Иван решил запустить книжный интернет-магазин и начал анализировать, какие подобные сайты уже представлены в сети. Собрал информацию об их трафике, функциональности.

Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.

Создание. Иван заключил с разработчиками договор. Они начали писать код, отрисовывать дизайн, составлять документацию.

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

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

А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.

Основные модели разработки ПО

  • Code and fix — модель кодирования и устранения ошибок;
  • Waterfall Model — каскадная модель, или «водопад»;
  • V-model — V-образная модель, разработка через тестирование;
  • Incremental Model — инкрементная модель;
  • Iterative Model — итеративная (или итерационная) модель;
  • Spiral Model — спиральная модель;
  • Chaos model — модель хаоса;
  • Prototype Model — прототипная модель.

Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.

Waterfall (каскадная модель, или «водопад»)

В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.

Преимущества «водопада»

  • Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты, может управлять сроками и стоимостью.
  • Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до».
  • Не нужно нанимать тестировщиков с серьёзной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию.

Недостатки каскадной модели

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

«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО. 

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

V-образная модель (разработка через тестирование)

Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х.

Преимущества V-образной модели

  • Количество ошибок в архитектуре ПО сводится к минимуму.

Недостатки V-образной модели

  • Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».

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

Incremental Model (инкрементная модель)

Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.

  1. Заказчик решил, что хочет запустить соцсеть, и написал подробное техническое задание. Программисты предложили реализовать основные функции — страницу с личной информацией и чат. А затем протестировать на пользователях, «взлетит или нет».
  2. Команда разработки показывает продукт заказчику и выпускает его на рынок. Если и заказчику, и пользователям социальная сеть нравится, работа над ней продолжается, но уже по частям.
  3. Программисты параллельно создают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и других действий, согласованных с заказчиком. Инкремент за инкрементом они совершенствуют продукт, приближаясь к описанному в техническом задании.

Преимущества инкрементной модели

  • Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок — и по итогам обратной связи решает, продолжать ли разработку.
  • Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен.
  • Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.

Недостатки инкрементной модели

  • Каждая команда программистов разрабатывает свою функциональность и может реализовать интерфейс продукта по-своему. Чтобы этого не произошло, важно на этапе обсуждения техзадания объяснить, каким он будет, чтобы у всех участников проекта сложилось единое понимание. 
  • Разработчики будут оттягивать доработку основной функциональности и «пилить мелочёвку». Чтобы этого не случилось, менеджер проекта должен контролировать, чем занимается каждая команда.

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

Iterative Model (итеративная модель)

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

Рассмотрим на примере создания мессенджера, как эта модель работает.

  1. Заказчик решил, что хочет создать мессенджер. Разработчики сделали приложение, в котором можно добавить друга и запустить чат на двоих.
  2. Мессенджер «выкатили» в магазин приложений, пользователи начали его скачивать и активно использовать. Заказчик понял, что продукт пользуется популярностью, и решил его доработать.
  3. Программисты добавили в мессенджер возможность просмотра видео, загрузки фотографий, записи аудиосообщений. Они постепенно улучшают функциональность приложения, адаптируют его к требованиям рынка.

Преимущества итеративной модели

  • Быстрый выпуск минимального продукта даёт возможность оперативно получать обратную связь от заказчика и пользователей. А значит, фокусироваться на наиболее важных функциях ПО и улучшать их в соответствии с требованиями рынка и пожеланиями клиента.
  • Постоянное тестирование пользователями позволяет быстро обнаруживать и устранять ошибки.

Недостатки итеративной модели

  • Использование на начальном этапе баз данных или серверов — первые сложно масштабировать, а вторые не выдерживают нагрузку. Возможно, придётся переписывать большую часть приложения.
  • Отсутствие фиксированного бюджета и сроков. Заказчик не знает, как выглядит конечная цель и когда закончится разработка.

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

Spiral Model (спиральная модель)

Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту модель начали использовать в 1988 году.

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом». 

  1. Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут её реализовывать, разработали, протестировали и «выкатили» конечный продукт.
  2. Заказчик оценил результат и риски: насколько нужна пользователям следующая версия продукта — уже с управлением телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты действовали по каскадной модели и представили заказчику более сложный продукт, разработанный на базе первого.
  3. Заказчик подумал, что пора создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, да и производители не заинтересованы в сотрудничестве по этому вопросу. Следовательно, риски превышают потенциальную выгоду. На основе полученных данных заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность, чтобы со временем понять, как развивать систему «Умный дом».

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

Преимущества спиральной модели

  • Большое внимание уделяется проработке рисков.

Недостатки спиральной модели

  • Есть риск застрять на начальном этапе — бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.
  • Разработка длится долго и стоит дорого.

На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.

Что такое Agile?

Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:

  • экстремальное программирование (Extreme Programming, XP);
  • бережливую разработку программного обеспечения (Lean);
  • фреймворк для управления проектами Scrum;
  • разработку, управляемую функциональностью (Feature-driven development, FDD);
  • разработку через тестирование (Test-driven development, TDD);
  • методологию «чистой комнаты» (Cleanroom Software Engineering);
  • итеративно-инкрементальный метод разработки (OpenUP);
  • методологию разработки Microsoft Solutions Framework (MSF);
  • метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
  • метод управления разработкой Kanban.

Различия между Agile и традиционным подходом к разработке мы свели в таблице:

Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban. 

Kanban

Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания. 

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

Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!

Источник

Понравилась статья? Поделить с друзьями:

Интересное по теме:

  • Codesys ошибка 3611 неверная директория компиляции
  • Code 554696704 call of duty mobile ошибка
  • Code 2 safe ошибка на поло
  • Code 16 шевроле авео т300 ошибка
  • Code 154140716 call of duty mobile ошибка

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии