Обсуждание: Embedded Systems Architecture. A Comprehensive Guide for Engineers a

[RXL]

https://forum.shelek.ru/index.php/topic,26526.msg286011.html#msg286011

Прочитал пока ≈2/3 (страница 459 из 657). По началу пробовал читать все, но оказалось, что это пустое занятие (первые 20 страниц можно смело пропустить). Стал листать и читать выборочно. Section 1 и 2 можно смело пропускать: для человека даже поверхностно знающего электронику и микропроцессоры это пустая информация. Такой каши из разных областей я еще не видел. Для кого это? Для начинающего слишком сумбурно. Для середняка (я себя отношу к этой квалификации) бесполезно. Один и тот же материал повторяется по 2-3 раза, за одно и иллюстрации. Насчет section 3 пока воздержусь: там есть новые для меня термины в описаниях планировщиков и, может быть, там найдется что-то полезное. Перечитаю эту часть еще раз. Но и она тоже содержит кашу, хоть и в меньших количествах. Прочитаю дальше, дополню свои впечатления.

[Dimka]

Раз уж пошла такая пьянка

https://forum.shelek.ru/index.php/topic,28557.msg285917.html#msg285917

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

[RXL]

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

[Dale]

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

Подачи как таковой вообще нет, скорее перечень тем, которые следует поштудировать. Этакий примитивный вариант Body of Knowledge, а не учебное пособие.

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

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

[RXL]

По моему логично, что требования первичны.

[Dale]

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

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

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