Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Обсуждание: Embedded Systems Architecture. A Comprehensive Guide for Engineers a  (Прочитано 9851 раз)
0 Пользователей и 1 Гость смотрят эту тему.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« : 23-01-2013 20:04 » 

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

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

Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 23-01-2013 22:42 » 

Раз уж пошла такая пьянка Улыбаюсь

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 24-01-2013 09:58 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dale
Блюзмен
Модератор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 24-01-2013 19:14 » 

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

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

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

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4 : 24-01-2013 20:49 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dale
Блюзмен
Модератор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 24-01-2013 21:34 » new

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

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines