Что такое agile и waterfall

Что такое Waterfall и чем он отличается от Agile

Что такое Waterfall и чем он отличается от Agile

Старший маркетолог ООО «Диалог Информационные Технологии»

Специалист-консультант ООО «Диалог ИТ»

Что такое водопадный подход

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

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

Минусы Waterfall

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

Некоторые из недостатков водопадной модели попытались исправить в одной из ее модификаций: Sashimi Waterfall (Сашими). В ней этапы, как и в оригинальной методике, идут друг за другом, но при этом перекрываются один другим во времени. Это позволяет начать разработку дизайна еще на этапе сбора информации, а значит, добавляет так сильно недостающую гибкость в процесс. Затраты при этом растут не сильно, а сама методология не превращается в Agile.

Waterfall или Agile: какой подход выбрать?

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

Доступность для заказчика

Заказчик дает комментарии по ходу разработки

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

В любой из методологий вовлеченность заказчика уменьшает риски

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

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

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

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

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

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

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

Координация и слаженность команды ограничена точками передачи ответственности (при переходе с этапа на этап)

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

Отлично работает в случаях, когда деньги и время не имеют жестких ограничений, но работа ухудшается при появлении рамок

Уменьшает риски при наличии фиксированной цены, так как договоренности установлены заранее

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

За отсутствием ограничений – Agile более предпочтителен

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

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

Источник

Agile или Waterfall — какой вариант соответствует вашему бизнесу?

Противостояние Agile и Waterfall не столько теоретическое, сколько практическое. Выбор методики, не подходящей под ваш проект, в лучшем случае существенно затормозит его развитие, в худшем — отправит в список «ТОП-провалов года».

Гибкая и каскадная модели разработки проекта (Agile и Waterfall соответственно) — одни из наиболее популярных среди прочих методологий управления. Изучив особенности конкретно вашего проекта, и вооружившись знаниями из этой статьи, вы сможете с полной уверенностью ответить на вопрос: «Что подойдёт моему бизнесу — Agile или Waterfall?»

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

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

Что такое Agile

Как и другие популярные методологии разработки и управления проектами, Agile появился сравнительно недавно в США. В отличии от CPM и CCPM, за появление гибкой методологии разработки ответственна сразу целая группа людей — 17 американских IT-специалистов из штата Юта. Вместе с «Манифестом гибкой разработки ПО», в котором впервые прозвучал термин «Agile» они прописали 12 принципов Agile-разработки.

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

Scrum — методология гибкой разработки на основе Agile, в основе которого лежит «спринт» — отрезок от 1 до 4 недель, по окончанию которого должна быть получена рабочая версия продукта.

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

Экстремальное программирование (XP) — одна из Agile-методик, где важная роль отводится периодической игре в планирование с привлечением заказчика. Она позволяет определить недостатки предыдущей итерации, приоритетность задач, желаемую функциональность продукта с учётом пожеланий заказчика.

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

К преимуществам метода относятся:

Не избежала методология и недостатков, которые органично «дополняют» её достоинства:

Что такое Waterfall

Методика Waterfall (водопадная система разработки) — детище Винстона Уолкера Ройса, директора Lockheed Software Technology Center в Остине (штат Техас, США), пионера в области разработки программного обеспечения.

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

В оригинальной работе Уолкера «Managing the development of large software systems» описаны 6 стадий разработки продукта, которые в 1985 году Департамент защиты США закрепил в стандартах работы с разработчиками программного обеспечения:

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

В число наибольших преимуществ методики Waterfall вошли:

Среди недостатков водопадного метода можно выделить:

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

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

Waterfall с субпроектами — модель, в которой вы работаете с трёмя крупными блоками: концептуализацию, проектирование требований и архитектурная структура продукта. Затем для каждого из них вы проходите стадии (субпроекты) детального проектирования, кодирования и тестирования. В конце проводится интеграция всех компонентов на этапе тестирования системы.

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

Сравнительная таблица

Гибкая модель разработки, основанная на
итеративных принципах

Каскадная система разработки, основанная на жёсткой последовательности процесса разработки

1956 г., 1961 г., 1970 г.

Группа IT-специалистов (США)

Г. Беннингтон, Хозьер, В. Уолкер Ройс

Unilever, ряд банков (Альфа Банк, Home Credit, Райффайзен Банк и т.д.)

Cisco Ericsson AB, Toyota (до 2010)

Источник

Waterfall и Agile: и всё-таки, откуда эффект?

Всем добрый день! Этот короткий пост посвящен рассмотрению моделей процессов разработки Waterfall и Agile (на примере Scrum и/или Kanban). И вот в чем дело: с точки зрения заказчика, процесс не столь важен, сколько срок и бюджет удовлетворительного с точки зрения функционала результата. И если известно, что (изменения не учитываются) затраты Waterfall-процесса идут по S-кривой, а затраты Agile-процесса накапливаются линейно (так как ресурсы используются одновременно все), то как они должны различаться по эффективности. Чтобы исследовать этот вопрос, необходимо построить модели и сравнить их, и для этого будет использована несложная математика.

Предыстория

Управление проектом, условно, можно разделить на две составляющие — на планирование и управление ходом.

С этой точки зрения для waterfall всё ясно — составили пошаговый (аналитика-разработка-тестирование) календарный план задач по оценкам сроков, распределили задачи и вперед реализовывать.

Со Scrum и Kanban ненамного сложнее: последовательность планирования осуществляется через приоритеты в backlog, разработка контролируется либо через burndown chart для всего проекта (в Scrum), либо с помощью lead time (в Kanban). Оценка сложности задач влечет за собой и оценку сроков — через тройку итераций или задач становится ясной скорость, на основе которой можно давать оценку даты окончания.

В данном посте ход проекта моделироваться не будет (это вообще себе вполне отдельная задача), а будет сравниваться эффективность плановая.

«На кончике пера»

Откуда, собственно, ясно следующее:

На этом пока с Agile закончим, к счастью модель его плана оказалась (в моей версии) достаточно проста. Всё становится сложнее с Waterfall-планом, так как в нём привлекаются специалисты по ходу проекта. При этом, однако, остается основное соотношение:

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

Зная, что p(0) = 0, можно выписать интеграл p'(t):

p(t) = 2 * N * t^2 / (r * T) — 4 * N * t^3 / (3 * r * T^2) => T = 3 * P * r / (2 * N).

О! А вот это уже интересно! При выбранном законе привлечения команды к проекту по времени, длина проекта вырастает в полтора раза! А ведь ситуация с привлечением не всего персонала сразу типична для Waterfall.

Что у нас со стоимостью? Её также можно найти интергированием (по t).

s'(t) = c * n(t) => s(t) = 2 * c * N * t^2 * (3 * T — 2 * t) / (3 * T^2),

S_W = 2 * c * N * T / 3 = c * P * r.

Кривые

Убедимся, что мы получили S-кривую на отрезке [0; T]. Подставим значения с = 1, r = 2, P = 100, N = 10 и получим T = 30.

График p = p(t) для Waterfall:

График s = s(t) для Waterfall:

Немного выводов

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

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

Источник

Методология разработки Waterfall: что это, как работает и чем отличается от Agile

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

Бывает, что в теории методология ясна, а потом дело доходит до внедрения и начинаются вопросы. На курсе «Руководитель digital-проектов» преподаватели Skillbox разбирают инструменты управления на реальных кейсах, чтобы студенты легко и безошибочно применяли их в работе.

Что ещё за Waterfall?

Waterfall — модель «Водопад», водопадная или каскадная разработка продуктов. Она подобно потоку воды направляет команды решать задачи последовательно и строго по изначальному плану. Название появилось в 1970 году в статье Винстона Уолкера Ройса, директора Lockheed Software Technology Center, а структура позаимствована у диаграммы Ганта.

Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства
CRM-маркетинга Out of Cloud.

Принципы водопадной модели разработки

Как работает Waterfall

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

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

Команда создаёт прототип и готовит дизайн-макеты. Когда это готово, подключаются разработчики.

На этом этапе пишут код продукта согласно плану, макетам и требованиям. Ни шагу в сторону, всё четко по ТЗ.

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

Эксплуатация и поддержка

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

Как отличить Waterfall от гибких методологий

Классическая методология Waterfall — это работа по заранее написанному и согласованному ТЗ. Гибкость здесь не приветствуется. В этом основное отличие водопадной модели от Agile.

Waterfall отличается от Agile и самими принципами работы, о которых мы говорили выше.

12 принципов Agile

Эти принципы появились из agile-манифеста.

Манифест гибкой разработки ПО

Если бы для Waterfall тоже написали манифест, он бы выглядел так:

Манифест водопадной модели разработки ПО

Чем Waterfall отличается от Scrum

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

Если хотите разобраться подробнее:

Заключение

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

В Digital такое бывает редко, поэтому команды добавляют к каскадной модели гибкие практики: например, проверяют продукт на соответствие требованиям после каждого этапа работы, а не в самом конце.

Источник

(Agile vs waterfall) Разработка критически важных алгоритмов: Проектирование

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

Водопады потрясают по самой своей сути, так что неудивительно, что инженеры немного одержимы ими. Старый стандарт DOD-STD-2167A рекомендовал использовать водопадную модель, а мое устаревшее инженерное образование основывалось на модели Phase-Gate, которая, по моему мнению, чертовски похожа на водопадную. С другой стороны, те из нас, кто изучал информатику в университете, наверное, знают, что водопадная модель в некоторой мере является анти-паттерном. Наши друзья в академической башне из слоновой кости говорят нам, что нет-нет, Agile — это путь к успеху и похоже, индустрия доказала истинность этого утверждения.

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

Как обычно в жизни, ответ находится где-то посередине.

Гибридная, спиральная и V-образная модели

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

Звучит неплохо, но насколько это действительно эффективно?

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

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

Практическое применение

Говоря более конкретно, мы с рабочей группой NDT в Autoware.Auto, закончили наш первый спуск по левому каскаду V-образной модели (то есть совершили первую итерацию через этап проектирования) в рамках подготовки к Autoware Hackathon в Лондоне (его проводит Parkopedia!). Наш первый проход через этап проектирования состоял из следующих этапов:

Обзор литературы и существующих реализаций

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

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

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

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

Из нашего обзора литературы по NDT, мы собрали следующие полезные фрагменты информации:

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

Варианты использования, требования и механизмы

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

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

Варианты использования

Мне нравятся три мысленных подхода к вариантам использования (внимание, я не специалист по функциональной безопасности):

Требования

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

В конце концов, общие требования к системе локализации не так уж и страшны:

Механизмы

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

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

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

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

Анализ неисправностей

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

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

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

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

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

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

Всего мы выработали 15 рекомендаций. Я бы рекомендовал вам ознакомиться с ними.

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

Определение метрик

«То, что измеряется поддается управлению»
— Популярная фраза менеджеров

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

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

Для нашей реализации NDT мы разбили метрики на четыре широкие группы:

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

Архитектура и API

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

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

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

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

Каковы же тогда степени свободы в NDT?

Обзор литературы говорит нам о том, что существуют различные способы представления сканирования и наблюдения (например, P2D-NDT и D2D-NDT). Аналогичным образом, наш инженерный документ высокого уровня говорит о том, что у нас имеется несколько способов представления карты (статический и динамический), так что это тоже степень свободы. В более свежей литературе также говорится о том, что задача оптимизации может быть пересмотрена. Тем не менее, сравнивая практическую реализацию и литературу, мы видим, что даже детали решения для оптимизации могут отличаться.

И список можно продолжать и продолжать.

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

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

Далее

После проектирования, конечно, приходит время реализации. Официальная работа по внедрению NDT в Autoware.Auto была проведена на хакатоне Autoware, организованном Parkopedia.

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

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

Подписывайтесь на каналы:
@TeslaHackers — сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla
@AutomotiveRu — новости автоиндустрии, железо и психология вождения

Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

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

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

Источник