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

17

Я всегда задавался вопросом, как применять гибкие методы на самом деле в большом сложном встроенном системном программном обеспечении (более 100 инженеров). Разработка встроенного программного обеспечения обладает некоторыми уникальными характеристиками, которые затрудняют гибкую работу (т. Е. Аппаратное обеспечение недоступно до конца цикла разработки; после выпуска продукта невозможно легко обновить встроенное ПО; и т. Д ...)

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

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

Hopia
источник
Я понимаю, что завершенное оборудование не будет доступно до конца цикла разработки, но разве у вас нет прототипа или оборудования для отладки, платы разработки или, по крайней мере, симулятора производителя для тестирования? Или мы начинаем здесь с нуля?
Кевин Вермеер
3
Я говорил с проворным разработчиком о моей встроенной работе. «Выпуск каждые 6-8 недель!?!?» он сказал. «Это действительно долго». «Нет, ты не расслышал меня,» сказал я, «Это 6 до 8 месяцев »
AShelly
см. также stackoverflow.com/questions/4498476/…
AShelly
2
Мне любопытно, какой тип продукта имеет более 100 встроенных инженеров?
Пемдас,
@reemrevnivek - обычно есть доска объявлений из предыдущих проектов, которую можно использовать. Иногда они достаточно похожи на новый продукт. Даже тогда, несмотря на то, что все ваши тесты проходят на плате eval, когда вы фактически запускаете прошивку на конечном устройстве, тесты чаще всего прерываются, потому что были какие-то новые вещи, которые ребята решили добавить в последнюю минуту или, возможно, не упомянул нам в начале ....
Хопия

Ответы:

10

Я думаю, что два метода являются ключевыми:

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

  • Напишите множество юнит-тестов против симулятора.

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

Кристофер Джонсон
источник
Кроме того, производители чипов должны предоставить соответствующую часть кода симулятора.
Rwong
к тому времени, когда у вас есть эти вещи, конкурент уже отправил
Билл
Если у вас более 100 инженеров, вы, безусловно, сможете создать пригодный для использования симулятор за меньшее время, чем отправят ваши конкуренты. Это особенно верно, если ваши конкуренты не имеют возможности протестировать свое программное обеспечение, пока они не получат аппаратное обеспечение.
Кристофер Джонсон
Да, я согласен, что тренажеры являются ключевыми. Таким образом, проектирование всей системы с самого начала основано на том, насколько эффективно вы можете разбить систему на тестируемые компоненты. Теперь, как убедить всех этих людей в гибкости - это другой вопрос ........
Хопия,
@ Билл Это очень вероятно. Тем не менее, это, вероятно, означает, что они отправили непроверенный продукт низкого качества, а продукт ОП выдувает их из воды. Ну, по крайней мере, так и должно быть.
Хулио
2

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

Чтобы обеспечить JIT, каждый из поставщиков компании должен предоставить JIT.

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

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

С точки зрения «постепенного» развития (также известного как Tracer Bullets 15 лет назад), это будет означать, что «ядро» будет выпущено очень скоро для водителя, и что основной драйвер будет доступен для интегратора, и что графический интерфейс будет быть разработанным, бить одной кнопкой и полем редактирования одновременно.

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

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

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

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

xtofl
источник
+1 для agile только возможно, потому что основной материал тщательно разработан / сделан.
Билл
1

Agile Manifesto: http://agilemanifesto.org/

«Индивидуумы и взаимодействия над процессами и инструментами»

  • Встречайте больше. Нажмите на бумагу меньше.

«Работа программного обеспечения над исчерпывающей документацией»

  • Прототип и технология сборки пики рано и часто.

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

«Взаимодействие с клиентом при заключении договора»

  • Гиперкомплексные процессы контроля изменений - это просто способ сказать «нет» клиенту.

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

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

«Реагировать на изменения в соответствии с планом»

  • В то время как сложная интеграция требует сложного плана, общая «программа» (или последовательность проектов) не может быть сформулирована слишком рано.

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

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

С. Лотт
источник
0

Моя проблема с scrum во встраиваемых системах состоит в том, что есть много задач, особенно на ранних стадиях, которые не являются очевидными. Мы начали с доски разработки, без ОС, без дисплея, без последовательной связи и т. Д. У нас не было нашего дисплея для 6 спринтов.

Первыми 4 спринтами были: Подготовка и запуск ОСРВ Создание задач Написание сетевых и последовательных драйверов Написание подпрограмм прерывания для кнопок, сообщений и т. Д. Написание основных классов и методов базы данных Написание последовательной отладки

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

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

Мы закончили тем, что написали фразы «пользовательских историй», такие как «Как разработчик ...», что меня не устраивает, но при использовании Target Process (www.targetprocess.com) нет концепции элемента журнала, который задача или работа по дому.

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

Брюс
источник