Средства и методы разработки

Ну тема слишком большая, правда в ней только субъективная. Только потому и спорю, что вроде мы в одной области крутимся. Если вообще обстрактно, то вашу модель "водопада" давно признали устаревшей. См. Хассан Гома "UML. Проектирование систем реального времени, параллельных и распределенных приложений". Более прогрессивные модели создания ПО это модели временных прототипов и эволюционирующих прототивов. Обе неявно предпологают наличие работающего дивайса на самых ранних стадиях. Но главное НО в применении этих моделей в том, что цена ПО должна гораздо превышать цену железа. Иначе игра не стоит свеч. Т.е. пригодны эти методы для сложных заказных систем разрабатываемых большими коллективами. Малые встраиваемые системы под это никак не катят. В моей практике всегда стратегия была одна - кратчайшие сроки с минимильным BOM-м. Цена софта в микроконтроллере никогда сильно не отражалась на цене дивайсов. Если чувствовали, что разработка ПО затягивается и становится дорогой то сразу обрывали проект. Иначе это уже не малая встраиваемая система. При этом не говорю про поддерживающее ПО для PC. Это отдельная тема. Слава богу несложных тем еще хватает. Думаю так должно быть и в вашей практике. Так как софт пишет один человек, ну два, то этап планирования пропускается автоматически. Оптимизация бессмыслена т.к. работа начинается без конкретного ТЗ в начале. Чтобы время не уходило зря пока заказчик определяется, сразу рисуем ядро схемы и драйвера и запускаем первую итерацию PCB, т.е. в отличии от вашего метода двигаемся от драйверов к каркасу приложения. Да, когда заказчик с претензиями, то приходится нарисовать нечто вроде UML схемы для его диагамм прецедентов и словесных спецификаций чтобы доказать их протеворечивость, но для этого же есть коммерческие мощные визуальные инструменты - Stateflow, Simulink, Rhapsody и т.д. которые в динамике все покажут. Минимальный BOM предпологает унификацию элементной базы, то есть мы уже не можем скакать с проца на проц после того как сделали выбор, значит и конфигураторы для разных платформ тоже излишество. Хорощо структурированный код еще не гарантирует хороших параметров производительности. Даже наоборот, например примение HAL с косвенными вызовами не дает компилятору и броузерам кода проследить все дерево вызовов заставляя программера все держать в памяти и ошибаться и долго искать утечки стека, heap-а, процессорного времени и т.д. Хотя HAL, конечно, обеспечивает идеальную модульность. Другой принцип - никаких гибридных языков для модификации исходников или замены C. Все это приводит к жесточайшим местным эффектам, наподобии того что я описал выше. Если бы я писал на Ch, то увидел бы проблему только в самом конце, когда было бы уже поздно. Я вообще писал бы на самом ограниченом подмножестве C - MISRA С еслиб не куча уже написанного софта.